Quick & Dirty Guide to making your own apt source directories (was Re: Administering large groups of Debian machines)
"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 jpb@creol.ucf.edu
ourapps Optional example/misc jpb@creol.ucf.edu
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 <jpb@creol.ucf.edu>
CREOL System Administrator
Social graces are the packet headers of everyday life.
Reply to: