Re: Reducing redundancy

[Adam Di Carlo]

Josip Rodin <[EMAIL PROTECTED]> writes:

> On Fri, Dec 15, 2000 at 11:23:35AM +1100, Adam Brown wrote:
> > As an example of the existing redundancy in the installation
> > documentation, from the documentation page I could potentially arrive at
> > three different installation guides:
> > 
> > http://www.debian.org/releases/stable/i386/install
> > http://www.newriders.com/debian/html/noframes/
> > http://www.debian.org/releases/potato/installguide/
> 
> Ah, that's a different kind of redundancy than one I thought about :)
> Basically, the first one is the official manual. The second one is a
> semi-random book about Debian, and the third is oriented towards newbies,
> with the screenshots, `loose' language and all.

I have read the 'installguide' (3rd one) and personally had nothing to
do with it and agree with Mssr Brown that document was unnecessary and
whatever work the author did for that document could have been better
spent on the main document (for which I have very little help).

But I have no power to tell people what to do.

> > Another issue is in the development of Debian specific sysadmin and
> > network manuals. It is a little disconcerting the way so much redundant
> > Linux documentation is being developed in parallel. Which reference
> > should a Debian user turn to: the Debian Network Admin guide, the Linux
> > Network HOWTO, the Linux Network Admin Guide or the myriad of other
> > contributed guides?
> > 
> > It would seem to make sense to me that Debian joined forces with the
> > developers of the Linux NAG and SAG and helped improve those and added
> > clauses where Debian specific issues arose.
> 
> Our System and Network administration guides are hardly finished, and they
> don't look like getting finished soon. I guess we need someone to actually
> write the docs about that on Debian systems, then it can be decided whether
> to make it a separate document or a part of the general Linux documents...

I again agree with Adam and disagree with you here, Josip.  Trying to
write the document first, then think about whether to integrate it
later is silly.  I personally think the Net admin guide should be
folded into the best and most-maintained general linux net admin guide
-- I see no purpose to the Debian-only one.

If there was a Debian-only sysdamin type guide it should be short and
not overarching, i.e., just stuff that is debian-centric.  See the
attached HTML file for a sketchy example.
-- 
.....Adam Di [EMAIL PROTECTED]<URL:http://www.onShore.com/>

Title: Sysadmin Hints on Debian Linux

Getting Along with Debian Linux (hints from Adam Harris <[EMAIL PROTECTED]>) If you're new to Debian, you might not know the following: the pkg management system owns much of your hard drive. The following directories should not be messed with manually unless you really know what you are doing: /usr (excluding /usr/local) /var (you could make /var/local and be safe in there) /bin /sbin /lib If you do mess around in there, you are liable to have whatever you did be stomped by upgrading a package. alternative versions of applications are managed by update-alternatives, man page for which (!!!!) still not shipped as of 4 June 1998, unfortunately. Basically, say, /usr/bin/vi -> /etc/alternatives/vi -> {nvi, vim, whatever you like}. You can set your preferred vi by modifying the symlinks in /etc/alternatives/. X configuration is a pain in the butt; but I suggest you use the XF86Setup program (part of the xserver-vga package). Sometimes that doesn't work, however. Documentation to be found in /usr/doc. To submit bugs, look at /usr/doc/debian/bug*. To read about Debian-specific issues, look at /usr/doc/<pkg>/README.Debian. The best installation method is apt. Get it from <debian_mirror>/project/experimental/. Once you have that, you can use it as a method from dselect; or you can use the command line version. Look at apt-get(8). Note apt also will let you merge, say, ftp1.debian.org with ftp.de.debian.org in such a way as you have the export-restricted packages (like pgp) as well as the std pkgs. The debian way of building a kernel is also somewhat different. Get the kernel-package pkg, get the kernel source tree (either debian version or standard linux archive kernel will work), install in /usr/src/linux (or symlink to that), and for any non-std modules (i.e., pcmcia) get that source too (debian module sources will install to /usr/src/modules). Then read /usr/doc/kernel-packages/README.gz. This method will make a .deb of your kernel source, and, if you have non-std modules, make a synchronized dependant .deb of those too. It's a better way to manage kernel images; /boot will hold the kernel, the System.map, and a log of the active config file for the build. Ever said, "Damn, where the fsck is that cron job"? Ever grepped thru /var/spool/cron/crontabs, had to su to some wierd user, then do crontab -e? Even had to look through all the cron jobs, thinking about whether they all happen to fire at the same time or not? Well, you don't have to anymore. Only personal cron jobs should be in /var/spool/cron/crontabs on a debian server. Any jobs under the purview of the system administrator should be in /etc, since they are configuration files. If you have a root cron job for daily, weekly, or nightly runs, put them in /etc/cron.{daily,weekly,monthly}. These are invoked from /etc/crontab, and will run in alphabetic order, which serializes them. On the other hand, if you have a cron job that (a) needs to run as a special user, or (b) needs to run at a special time or frequency, you can use either /etc/crontab, or, better yet, /etc/cron.d/whatever. These particular files also have an extra field that allows you to stipulate which the user under which the cron job runs. In either case, you just edit the files and cron will notice them automatically. No need to run a special command. For more information see cron(8), crontab(5), and /usr/doc/cron/README.Debian.