"Stephen A. Witt" wrote: > > I seem to have started a Debian thing in the company that I work for. It > seems to be spreading. As the number of machines that we configure with > Debian grows, system administration issues start to raise their ugly > heads. We've recently gotten a dedicated sysadmin guy to take over the > admin tasks. He is very knowledgeable on Solaris, HPUX, and probably some > others, but is new to Linux. He and I are having a bit of a debate right > now as to the most effective way to manage these machines. > > We've got NIS running and all user accounts are automounted from a Sun > Sparc running Solaris. We have a mixed Solaris, Linux installation. So far > so good. What our sysadmin would like to do (this is typically what he > does for other Unixes) is to install client machines with a very basic set > of functionality. Then he would compile each application that would be > provided and install it into a directory in /home (e.g. /home/cvs/bin), > which would also be automounted when necessary from one of the client > machines. I see this as a little silly when, for Debian at least, nearly > all of the applications we use are easily installed on all the machines in > the normal Debian way. Our sysadmin sees the Debian way as interesting, > but a requirement for him to visit 25 machines instead of 1. > > My question is, is there anyone out there, preferably a sysadmin type, who > has experience with this type of thing and could give us some advice.
You'd probably be better off rolling your own deb files for the apps that aren't already in debian and then adding a source entry to /etc/apt/sources.list. If you make a task package that depends on all your locally created packages, then installing a client is as simple as apt-get install ourtaskpackage after you've done the base install, and upgrading the clients later is as simple as 'apt-get update;apt-get upgrade' in cron on the clients, though I'm personally paranoid enough that I prefer to do it from the command line so I can see what is getting upgraded. deb files are very easy to make - you essentially just need working clean & install targets in the top level Makefile. The online documentation is pretty good, and you can take a look at the source of an existing package to clarify things. Once you've figured out how to make deb files, making a directory suitable for apt is also pretty easy - I just created a fake user, made ~user/public_html/dists/local/jpb/binary-i386, then added deb http://name.of.server/~user/ local example to my /etc/apt/sources.list Then I added a Makefile to ~user/public_html/dists/local/example/binary-i386 with the following contents: # Packages.gz: Packages -rm Packages.gz gzip -9 Packages Packages: dpkg-scanpackages . override dists/local/example/binary-i386 > Packages # end Makefile override contains lines like so ourscripts Important example/admin [EMAIL PROTECTED] ourapps Optional example/misc [EMAIL PROTECTED] Nothing bad happens if you don't list one of your packages in override, other than that you don't control where they show up in dselect's listing. When you make a new deb, copy it to the binary-i386 directory, cd there and run make. jpb -- Joe Block <[EMAIL PROTECTED]> CREOL System Administrator Social graces are the packet headers of everyday life.
