Xhier How-To document

Getting Started Documents

• man xhier - will lead you to other useful manpages about generalities
• man xhier-package-structure
• man xh-distribute - manpages for individual xhier commands will start with xh-<command>
• man xhier-tools
  • xh-ancestors
  • xh-descendants
  • xh-packages
  • xh-available-packages

Finding what packages are on a given system

All xhiered software lives in /software, so the easiest thing is usually to cd /software and use ls to find a particular package, eg to find the packages for 'firefox', try:

@cscf[104]% cd /software
@cscf[105]% ls -ld *firefox*
lrwxrwxrwx   1 root     other         22 Jun  8  2006 mozillafirefox -> mozillafirefox-1.5.0.1
drwxr-xr-x   7 root     other        512 Jun 12  2006 mozillafirefox-1.0.6
drwxr-xr-x   7 root     other        512 Jun  5  2006 mozillafirefox-1.5.0.1
drwxr-xr-x   7 root     root         512 Nov  5 13:50 mozillafirefox-2.0

Note: cscf.cs is a good choice to get a list of most xhier packages we work with. The full list would be found on capo.uwaterloo.ca (the "grand boss" of all xhiered software!)

Finding out where a package is distributed from

• xh-dist-hosts -F -p [packagename]

Note: make sure you have the full and complete name of the package. Look in /software to be sure (see notes, above)

Pushing out a package

To all descendant configured hosts

• xh-distribute [packagename]

To one particular host

• this will push it to that host, whether or not it was previously configured to receive it. It will now be configured to receive this package.

1. go to the arch-master machine
2. become root
3. setenv LOGNAME <youruserid>
4. setenv USER <youruserid>
5. xh-dist2 targetmachine packagename
   • eg: xh-dist2 curupira.math samba-2.2

• After pushing out the package, you may need to go to the machine to install it (see below)

Install package on target machine:

• Once the package is on the machine, it needs to be installed:
  1. login as root on target machine
  2. xh-install packagename
• If you want this version to be the default, you will need to "assert" it (see below)

Assert the current version as the default version

• If this version is later than an existing version, you may wish to make this new version the default. If so, follow the steps below:
  1. login as root on target machine
  2. xh-assert-version -f pacakgename
  3. xh-install packagename
  4. xh-make-links

Path Commands

• setenv PATH `showpath ${HOME}/bin standard`
• setenv PATH `showpath ${HOME}/bin standard u=m` include maintenance commands

Listing Software

• xh-packages -p
  • available via the standard search rules
• man software
  • complete list of the software packages

Finding out info about a package

• in /software/packagename/.admin
  • Synopsis - a brief description of the package
  • Maintainer - who "maintains" the package
  • HostMaintained - which host is this package maintained on

Creating a package from scratch

Investigate man xh-mkpkg and man xhier-package-names.

see: ST #47432 for one simple case. A quick description of all of the steps taken in that case:

%  xh-mkpkg perl-5-vendor
%  vi /software/perl-5-vendor/.admin/Maintainer
%  vi /software/perl-5-vendor/.admin/Synopsis
%  vi /software/perl-5-vendor/.admin/Install
%  vi /software/perl-5-vendor/.admin/Options  # change:   versionOf=perl perl-5
%  cd /.software/share/perl-5-vendor/bin
%  ln -s /usr/bin/perl perl

And the package is complete.

To install on the same host:

%  xh-install perl-5-vendor
%  xh-make-links

on re-logging in, 'which perl' should return: '/software/.admin/bins/bin/perl'

MikePatterson: you'll also want to read through the rest of the Options file, other items of particular interest are the package maturity (defaults to unknown which can drive some people batty). Others may say that one ought to batch the install and make-links steps.

Enabling passwordless login on Ubuntu

• install xinetd (in hardy it will read /etc/inetd.conf as there a directive in /etc/default/xinetd that says it ought to (the file /etc/inetd.conf is NOT created by the installation of xinetd, see below for how it should be enabled).

• install package rsh-redone-server (this adds entries to /etc/inetd.conf, but does NOT create it if does not exist, see below for more about how this should be done when using xinetd instead of inetd) and rsh-client-redone (they appear to be more secure). When installing on a hardy machine one sees

            Setting up rsh-redone-server (81-2) ...
            --------- IMPORTANT INFORMATION FOR XINETD USERS ----------
            The following line will be added to your /etc/inetd.conf file:
            
            shell      stream   tcp   nowait   root   /usr/sbin/tcpd   /usr/sbin/in.rshd
            
            If you are indeed using xinetd, you will have to convert the
            above into /etc/xinetd.conf format, and add it manually. See
            /usr/share/doc/xinetd/README.Debian for more information.
            -----------------------------------------------------------
            
            --------- IMPORTANT INFORMATION FOR XINETD USERS ----------
            The following line will be added to your /etc/inetd.conf file:
            
            login      stream   tcp   nowait   root   /usr/sbin/tcpd   /usr/sbin/in.rlogind
            
            If you are indeed using xinetd, you will have to convert the
            above into /etc/xinetd.conf format, and add it manually. See
            /usr/share/doc/xinetd/README.Debian for more information.
            -----------------------------------------------------------
         

NOTE. The file =/etc/inetd.conf was not created since we did not install inetd! However, if you touch /etc/inetd.conf prior to installing rsh-redone-server it will create the entries

    shell      stream   tcp   nowait   root   /usr/sbin/tcpd   /usr/sbin/in.rshd
    login      stream   tcp   nowait   root   /usr/sbin/tcpd   /usr/sbin/in.rlogind
    

You should get rid of the entry for in.rlogind as there is no need to via rsh protocol (use ssh), the only requirement is that there be output for a command, for example rsh host ls -al should return output provided you add an entry for that host in /root/.rhosts. NOTE. If you installed rsh-redone-server without first touching /etc/inetd.conf you will need to run apt-get --purge remove rsh-redone-server and then install it after you have touched /etc/inetd.conf.

The message above points out =/usr/share/doc/xinetd/README.Debian which has the following content:

             README.Debian for xinetd
             ========================
             
               xinetd in debian is supposed to work with -inetd_compat enabled (you can
               tweak that in /etc/default/xinetd).
             
               Package maintainers that support xinetd in addition to xinetd, will drop
               files in /etc/xinetd.d/ _and_ add entries in /etc/inetd.conf,
               enabling them using update-inetd.
             
               If both an xinetd service configuration id and an entry in /etc/inetd.conf
               match, the xinetd one will hide the inetd.conf one, even if disabled. This
               trick is built to simplify the logic in update-inetd, and let the
               administrators only touch xinetd configuration and don't have
               /etc/inetd.conf mess with that they changed behind their back.
             
              -- Pierre Habouzit   Wed, 28 Nov 2007 11:55:48 +0100
    

In hardy we see that INETD_COMPAT=Yes appears in /etc/default/xinetd. This allows xhier to work without requiring ports to xinetd. I like xinetd as it's easier to work with and some programs require it's presence (for example, vmware-server).

• remove or rename /etc/securetty (this may not be necessary)
  • or, add lines for pts/0 through pts/10

# additions for xhier remote rsh

pts/0
pts/1
pts/2
pts/3
pts/4
pts/5
pts/6
pts/7
pts/8
pts/9
pts/10

1. ) add /root/.rhosts add hosts that need root access. Should be confined to the arch master usually.
2. ) see if it works. If so, you're done.
3. ) if not, redirect /etc/alternatives/rsh from /usr/bin/ssh to /usr/bin/rsh (? Mike says this might be necessary; I (Daniel) didn't find it necessary). MikePatterson - update-alternatives is supposed to be run when the package is installed. I found with early sarge systems that this didn't seem to happen. It may depend on the order in which packages are installed. I haven't seen it lately (since approx. summer 2004).

Note: Instead of removing /etc/securetty, you can add an entry for rsh in it, which is probably a better idea. Also, at least for RedHat, the default for rsh, as enforced by PAM, is to NOT prompt for passwords. You MUST have a .rhosts file for rsh to let you through. -- ChristopherCalzonetti - 07 Mar 2005

Since I always end up looking here by mistake, a cross-reference to: SSHHostBasedAuthentication for enabling ssh (passwordless) host-based authentication. -- DanielAllen - 28 Sep 2005

Upgrading the OS on an Xhier'ed system

It is very important to follow the steps below when upgrading the OS on an existing Xhiered system.

• identify existing packages
• check configs and home directories
• *un*install all of the packages
• upgrade/re-install the OS
• install the new packages
• determine the impact of these upgrades
• see also: man xhier-os-upgrade

Diagnosing xhier problems with no error messages

Say you're trying to install a package, and it doensn't return any error message, for example:

# xh-dist2 host package
xh-dist2 FYI: checking all dependencies.
xh-dist2 FYI: using "xh-alter-requests -a package" on host "host".
xh-dist2: failed to update configuration on host "host":
xh-dist2: ***Nothing sent: aborting command***

First: what does the install command actually do?

on the host, (in this case) try running "xh-alter-requests -a package" by hand, which might result in output.

Next, if it's a csh script, try running it with the csh debugging switches:

/bin/csh -vx /software/.admin/bins/*/xh-alter-requests -a perl-5-vendor

Removing a package from a machine

xh-rm-package [packagename] /not/ xh-install -u (this is described in manpage xh-tools along with many other useful commands, and I put it here because I may need to search for it again)

Removing many packages from a machine

Conversation between Daniel Allen and Ray Butterworth on xhier101 mailing list, Tue, 15 Nov 2005:

>  I just tried xh-rm-package starting at the bottom of the list... and
>  quickly ran into a package that depended on another package.  I could
>  repeat this 40 times, OR write a script to do it, but I'd rather not
>  reinvent the wheel.
>
>  One method I've seen used (!) is repeatedly running xh-rm-package naiively
>  on all of the packages in turn until there aren't any left.  I could do
>  that, but it seems a bit inelegant.

"xh-rm-package -f ..." will make it ignore any dependencies.
[Question: when is this dangerous, as noted in the manpage?
In addition to leaving installed packages with missing dependencies,
it could also strand packages on other machines if the machine
that you removed the package from distributes that packge to others.
e.g. remove a package from cscf.cs, and it won't get any more
updates on any of cscf.cs's client machines.]


>  Plus I don't know if xh-rm-package
>  leaves a trail of comments behind in some config/*/requests file...

Whenever you remove a package, unless you specify "-k",
it adds a "-packageName" to /software/xhier/config/local/requests.

So, once you've removed them all (and assuming the original admin
requests are no longer in effect) you might want to edit that file
to remove all the added noise.

So: one automated solution is:

xh-packages -p > pkgs;                       # then edit out any you want to keep; 
cat pkgs | xargs -l1 -p xh-rm-package -f     # or without the -f if you're feeling less brave
                                             # clean up /software/xhier/config/local/requests

Step by step for setting up a new Ubuntu machine to be xhiered

UbuntuXhierHowto

-- DanielAllen - 19 May 2005

Putting packages on a remote share

Run of out space on your xhier store? PutSomePackagesElsewhere.