Initial notes by DanielAllen - 07 Apr 2005
Today Dave showed us the draft of his new script to automate ray's instructions from http://www.math/mfcf/internal/procedures/OS/Solaris/xhier_ray.html; and we had more Q&A.
I tried to get all the Q&A, but might have missed questions (feel free to fill things in / correct mistakes!!)
This will be part of dave's xhier_install package (which will exist soon) (note xhier naming convention: _ means subpackage)
Dave's script is called "xhier-it".
script named limit.xhier.requests will operate on:
/.software/local/xhier/config/local/requests which contains lines like:
-/software/xhier/config/admin/requests
-/software/xhier/config/regional/requests
which means we won't include those requests files.
[philosophy item about package whining: dave (& adrian) say: we should periodically be checking local-maintenance on all hosts... and fix things that whine. Which usually works, unless the package author did something in an unconventional way.]
Anyway, those {admin,regional}/requests files: may have lots of gunk such as sendmail-8.{1,2} when the most recent version is 8.3.
Can we remove the old packages from requests? no. multiple versions are necessary because some architectures somewhere in the tree below you may rely on the older ones.
dave says: check what packages aren't available for your architecture, or are redundant. go into your local/requests file and put -packagename, which override regional requests, which override admin requests.
either do this check manually every time set up a new master; or:
dave's idea: requests_obselete file which sits alongside requests file and will track the additional elements that are obselete. his script uses a routine Limit_Xhier_Requests to update local/requests automatically.
ray says: xh-requests doesn't complain if package not available. so this step might not be necessary. dave'll look into that.
going back to dave's script: He's assumes all files coming from one master.
dave's local/requests has lots of packages initially; xhier, os-extras, and mfcf-basics package that handles ssl rsync rcs
(others?)
dave checks /etc/defaultrouter (that needs to be fixed; it doesn't exist on linux...) and puts the default route into /software/os-extras/data/gateway
...that's about it (I think? -- DanielAllen).
Questions?
I asked how to do the work dave suggested in XhierOneZeroOne07Mar2005 related to config.h ... what's a good package to compile from scratch to test?
ray suggestsed I should compile xhier package because it's crucial.
Chris mentioned, as per last session and his bootstrapping issues, that he's been playing with writing a replacement for the 'absolute' command in perl.
We went looking in the source on capo for 'absolute' command.
mfcf-basics: absolute: dependss on mfcf-misc and library libuw.a
if you don't have xhier,dev installed on the destination, do xh-make on another system which will make a regular make-file (which is at least right for that arch). Copy the source and the newly created makefile (its name is "#xh-imakefile") to the base of your build tree, edit that makefile (look for optimizer, COMM_C, etc.)
Different (and maybe easier approach) would be: xh-make -n resolves that big makefile down to a command that actually gets run. it's much simpler to read (only a few lines)
to distribute source:
xh-sdist -n -m "clean all" -h <hostname>
expansion: distribute source... -n means do it now... -m means these are the make parameters passed...
dave ran an example. "distributing /usr/source/mfcf-basics/absolute"
it ran on all archmasters. no errors, yay.
if you're brave, "clean all install" will actually install it on all hosts.
rsh sun510 /usr/source/TEMP-CACHE/mfcf-basics/absolute/absolute ...fell down because sun510 doesn't have a necessary library
looking into that:
capo: where does OPT_CC get set? Dave and Ray think it's broken because IST isn't up to date with sun510.
Imake.template? to fix, sneak over to sun510 change __OPT_CC -O so it will use different cc flag.
ray has a checklist of what order to build packages from scratch to make everything work, though he says it's probably out of date. He uses it when diagnosing a package compile problem.
it's worth a look: mfcf.math:~rbutterw/Packages. [see below]. So perhaps I should try compiling mfcf-basics/arch_param .
We're skipping next Monday; the next meeting will be the following Monday at 2pm.
-- DanielAllen - 07 Apr 2005
I needed that same Packages file again, and rather than going over to mfcf.math to find it repeatedly, I'm just copying the whole thing here:
# Before anything else: # Create these userids: # accounts # console # daemon # jqpublic # operator # opnsutil # Create these groups if they aren't already there: # accounts # daemon # nobody # none # operator # opcons # source # Install these programs and these libraries: # mfcf-basics/arch_param (don't forget include/mfcf/config.h) # mfcf-misc/libcfix # mfcf-misc/libuw # Do these packages next: libmfcf login_dev accounts_dev lpr_dev nuwdir_dev termcap nettools_dev # Other things that will eventually be needed: # aceclient-2.1uw # cracklib # gnu * # gzip # secure-comm # secure-comm_dev * # Then xh-make-links # Then do these: mfcf-basics mfcf-misc mfcf-accounting console filetools games graveyard imake jqpublic lockfile nuwdir op-comm operations script security setpw shelltools tcsh vim-6.1 #Don't install these by default on some admins. accounts accounts_client accounts_obsolete accounts_special termcap_progs login ucb-login ucb-remote users # On Math Only accounts-master accounts-userids mfcf-accounting-master operations_master # On Dogen Only nuwdir-server # Obsolete archiver archiver-master # Gone #termfix
-- DanielAllen - 01 Sep 2005
see SettingUpNewUbuntuArches for specifics on installing these. -- DanielAllen - 21 Nov 2005