I believe what's happening is that GNU libc's malloc() often uses mmap() of/dev/zero to get large anonymous mappings. mmap() doesn't count against the memoryuse limit (RLIMIT_DATA in the code), which only covers things acquired via brk().
It appears that RLIMIT_AS, shown in bash as 'virtual memory (kbytes)' and available via ulimit -v, will limit total virtual memory usage, including all mmap()'d objects (and I think System V shared memory, from a peek at the code). Unfortunately it appears that csh/tcsh haven't been updated to know about this new thing-to-limit.
We've been doing this for years locally. The approach we use is to have a master machine on which all password changes happen (ssh has made this much easier to construct, since it is now very easy to run 'passwd' remotely with a pty). The master machine's/etc/passwd (and/etc/group) is then propagated out to all the client machines, and after this propagation each client strips off the 'system' accounts and groups that are specific to the master machine's OS and adds in its own (which are themselves propagated from a master, just in case we want to change them sometime).
There are a number of ways to propagate the files from master to clients. I prefer to use a solution where the clients each 'pull' the files from the master, since it works better if some of the clients are down or unreachable. The program we've historically used for this is something called track; you can get the version we use from the anonymous ftp server at ftp.cs.utoronto.ca in/pub. You could also use rsync's daemon mode, rsync over ssh to a carefully chosen captive account on the master, scp, or various other methods.
Track scales well and can be cascaded; we have multiple labs, and in each lab a single machine has been elected as the lab master; it tracks from the true master, and the other lab machines track from it. Our experiences with rsync's daemon mode have been less happy, but we were synchronizing a lot more with it (a hierarchy of local software, about 100 megabytes worth).
Security: our solution currently propagates the files in cleartext. I don't consider this a large problem in our environment, since we have to count on a secure network anyways (given that we do NFS and other things over it). With more work, it would be possible to transfer the files in some encrypted form.
The other problem with trying to be accurate (or slightly conservative) about the tape size to dump is putting multiple dumps onto the same tape. To get the sizing right, you need to tell dump how much tape is still left in the second and later dumps, which means capturing and parsing dump's output to find out how much of the tape has been used up by each filesystem.
For relatively simple situations (where you don't plan to pack tapes to the brim and don't plan on tapes ever overflowing), this is a chunk of somewhat arcane work for little purpose. On the other hand, if one really needs to do this, I suspect that things like Amanda have the code already. And researching the wheel is a lot easier than reinventing it.
Anyone looking for a project could always look into adding a switch to dump so that it produces program-friendly output that's easy to parse for this sort of information.
Often, there's not much point in giving dump plausible numbers about the tape size. If you're dumping in a situation where a tape that is unexpectedly full won't get swapped, you might as well tell dump whatever lie it needs so that it never thinks it needs to change tapes.
The Linux dump manpage I have handy even suggests that most of the time dump will directly notice end of media and deal with it properly, regardless of the tape size specified.
I suspect that all of DAT, DLT, and Exabyte 8mm tapes will be around and usable in five years (all of them are sufficiently popular now). Current generations of all of them store over 2G. Second hard drives that are active are susceptible to various problems, such as overheating, that can take them out at the same time as the main drive.
On the other hand: if you really want to make sure that the data stays usable over time, nothing beats keeping it on live disks. As JWZ mentions implicitly, various forms of backups risk either the hardware or the software (or both) no longer being capable of reading them a few years down the road. If the data is on your live disks, you will copy it around as you change and upgrade disks, machines, and operating systems, and will hopefully remember to keep being able to read it through this.
This isn't strictly a problem for pure backups (where everything in the backup is just a duplicate of what you have on the active drive), but most people and places wind up using things both for backup and for archival purposes. It may also be a problem for disaster recovery; if your existing computer melts down, can you still buy a tape drive that can read the machine's tape backups? (The paranoid (or just cautious) will also check the head alignment periodically to make sure that it hasn't drifted so that the tape drive is making tapes only it can read.)
The university I work at is currently going through this as we decomission the machine one of our last 9-track tape drives is on. We're having to sort through old 9-track tapes, work out what's important and what's not, coax the old hardware to read the tapes, and dump the data somewhere. (We're probably going to put much of it onto ISO-9660 format CD-Rs; hopefully that will have an equally good or better lifetime).
I think that a lot of decisions will depend on what sort of disasters you want to recover from. Planning for only 'normal' aging drives having media failures is a lot different (and easier) than planning for your office burning down.
There are all sorts of potentially problematic tradeoffs with various sorts of hard drives for backup. Things like:
a normal drive operating and in the machine is susceptible to common-mode failures that get both drives at once (such as overheating). If you keep it powered off it generally requires a reboot to see. External SCSI drives and some magic can avoid this.
Hot-swappable or otherwise removable HDs cost more and probably require rebooting the machine to use.
From what I understand, removable media like Zip and Jazz drives are not truly HDs, and are not as reliable as them (although they can be swapped in and out with the machine on). Repeated insert/write/remove cycles may expose you to a far-larger-than-HDs risk of media damage and data loss.
I suspect that everything short of Zip/Jazz cartridges are more susceptible to damage when removed than tapes. Especially if they aren't mounted in an external enclosure and are carried around with the drive electronics bare.
If you make more than one backup, tapes may become substantially cheaper than more and more HD space. If you store and handle lots of backups, again tapes may become easier and cheaper to deal with than other media.
I have a fairly high trust for the long term durability of tapes sitting around. Manufacturers test this stuff and will tell you about it, including cautions for temperature limits and so on. Do disk manufacturers give equivalent figures for removed drives?
For personal home use, I think that anything is better than nothing; a second HD is cheap and easy (especially if you aren't worried about things that would take both drives out at once, like overheating or fire). For professional use in an office or the like (even a home office), I'd trust tape more. The up-front costs are bigger, but the benefits can be substantial, and there are things that are far more convenient with tapes that are very important for professional use (such as periodic offsite backups).
If you trust tapes they can also be used for archival purposes (where you delete the data off the HD after storing it on tape and verifying the tape) as well as normal backups. Depending on how much call you have for this, this may also represent a money savings with tape over disks.
I think there's perhaps two questions being asked: how to become a competent sysadmin, and how to get hired doing the job. They've got different answers; some people have been answering one, some people have been answering the other.
In order to be a good, competent sysadmin I think you need to understand Unix and the Unix philosophy. Once you grok the philosophy, it is much easier to predict and use Unix, because things make sense. The best book for this that I've ever read is Kernighan and Pike's The Unix Programming Environment. As a side benefit, it will teach you a good amount about the basic tools. It is somewhat dated and assumes that you can program.
Get experience on multiple different Unix variants. This will teach a number of valuable things: how things are different, how things are the same, and how to efficiently ferret out information on new things. Try to work on Unixes that vary as widely as possible, for maximum broadening. If you have a network, use it and work out how to manage several different Unixes so that the users (even if that's only you) won't notice and won't care which one they're using.
Learn debugging skills: how to rapidly figure out what exactly is going wrong in a broken thing and how to dive in to tweak it so it works again. I don't know of any good books on this (and it's probably only taught implicitly at your local university), but it is a skill that a sysadmin will use over and over again. Learn how to poke through a system to see how it does a particular thing.
Learn how to program if at all possible. Not just writing scripts, but really programming. I think that in the long run all the interesting and sustainable bits of system administration will involve being able to do so. Sooner or later all the easy stuff will be automated or become grunt-work of filling in forms or changing backup tapes, done by people who are essentially clerks.
In my opinion, good sysadmins don't know everything, but they do know how to find it out; they learn fast and they can ferret out that little necessary tidbit of information. Learn how to find things out on Unix systems; man pages, GNU texinfo, whatever local proprietary system a Unix vendor may have added, and so on. Information, especially on a Unix system, has a structure; grok it, exploit it, and predict it.
Learn how to read manual pages (an underrated but essential skill). When you can read the 7th Edition sh manpage and it makes sense, you have achieved this. (You can find the 7th Edition documentation at this URL.)
For getting hired, I have no really good ideas. If you know people in Human Resources departments (or who otherwise hire or filter people), ask them for what they look for in a resume that gets that first foot in the door. This may well be a certificate or a course, even if it doesn't teach you anything useful in the long term. HR often works on magic words.
A local Unix user's group may be a good way to get contacts, and maybe even get offered that first job; if nothing else, you can establish to the people who may hire you someday that you do indeed know what you're talking about. If there isn't a local Unix user's group, founding one is likely to get you fairly well known.
Slashdot Mirror
I believe what's happening is that GNU libc's malloc() often uses mmap() of /dev/zero to get large anonymous mappings. mmap() doesn't count against the memoryuse limit (RLIMIT_DATA in the code), which only covers things acquired via brk().
It appears that RLIMIT_AS, shown in bash as 'virtual memory (kbytes)' and available via ulimit -v, will limit total virtual memory usage, including all mmap()'d objects (and I think System V shared memory, from a peek at the code). Unfortunately it appears that csh/tcsh haven't been updated to know about this new thing-to-limit.
We've been doing this for years locally. The approach we use is to have a master machine on which all password changes happen (ssh has made this much easier to construct, since it is now very easy to run 'passwd' remotely with a pty). The master machine's /etc/passwd (and /etc/group) is then propagated out to all the client machines, and after this propagation each client strips off the 'system' accounts and groups that are specific to the master machine's OS and adds in its own (which are themselves propagated from a master, just in case we want to change them sometime).
There are a number of ways to propagate the files from master to clients. I prefer to use a solution where the clients each 'pull' the files from the master, since it works better if some of the clients are down or unreachable. The program we've historically used for this is something called track; you can get the version we use from the anonymous ftp server at ftp.cs.utoronto.ca in /pub. You could also use rsync's daemon mode, rsync over ssh to a carefully chosen captive account on the master, scp, or various other methods.
Track scales well and can be cascaded; we have multiple labs, and in each lab a single machine has been elected as the lab master; it tracks from the true master, and the other lab machines track from it. Our experiences with rsync's daemon mode have been less happy, but we were synchronizing a lot more with it (a hierarchy of local software, about 100 megabytes worth).
Security: our solution currently propagates the files in cleartext. I don't consider this a large problem in our environment, since we have to count on a secure network anyways (given that we do NFS and other things over it). With more work, it would be possible to transfer the files in some encrypted form.
The other problem with trying to be accurate (or slightly conservative) about the tape size to dump is putting multiple dumps onto the same tape. To get the sizing right, you need to tell dump how much tape is still left in the second and later dumps, which means capturing and parsing dump's output to find out how much of the tape has been used up by each filesystem.
For relatively simple situations (where you don't plan to pack tapes to the brim and don't plan on tapes ever overflowing), this is a chunk of somewhat arcane work for little purpose. On the other hand, if one really needs to do this, I suspect that things like Amanda have the code already. And researching the wheel is a lot easier than reinventing it.
Anyone looking for a project could always look into adding a switch to dump so that it produces program-friendly output that's easy to parse for this sort of information.
Often, there's not much point in giving dump plausible numbers about the tape size. If you're dumping in a situation where a tape that is unexpectedly full won't get swapped, you might as well tell dump whatever lie it needs so that it never thinks it needs to change tapes.
The Linux dump manpage I have handy even suggests that most of the time dump will directly notice end of media and deal with it properly, regardless of the tape size specified.
I suspect that all of DAT, DLT, and Exabyte 8mm tapes will be around and usable in five years (all of them are sufficiently popular now). Current generations of all of them store over 2G. Second hard drives that are active are susceptible to various problems, such as overheating, that can take them out at the same time as the main drive.
On the other hand: if you really want to make sure that the data stays usable over time, nothing beats keeping it on live disks. As JWZ mentions implicitly, various forms of backups risk either the hardware or the software (or both) no longer being capable of reading them a few years down the road. If the data is on your live disks, you will copy it around as you change and upgrade disks, machines, and operating systems, and will hopefully remember to keep being able to read it through this.
This isn't strictly a problem for pure backups (where everything in the backup is just a duplicate of what you have on the active drive), but most people and places wind up using things both for backup and for archival purposes. It may also be a problem for disaster recovery; if your existing computer melts down, can you still buy a tape drive that can read the machine's tape backups? (The paranoid (or just cautious) will also check the head alignment periodically to make sure that it hasn't drifted so that the tape drive is making tapes only it can read.)
The university I work at is currently going through this as we decomission the machine one of our last 9-track tape drives is on. We're having to sort through old 9-track tapes, work out what's important and what's not, coax the old hardware to read the tapes, and dump the data somewhere. (We're probably going to put much of it onto ISO-9660 format CD-Rs; hopefully that will have an equally good or better lifetime).
I think that a lot of decisions will depend on what sort of disasters you want to recover from. Planning for only 'normal' aging drives having media failures is a lot different (and easier) than planning for your office burning down.
There are all sorts of potentially problematic tradeoffs with various sorts of hard drives for backup. Things like:
I suspect that everything short of Zip/Jazz cartridges are more susceptible to damage when removed than tapes. Especially if they aren't mounted in an external enclosure and are carried around with the drive electronics bare.
If you make more than one backup, tapes may become substantially cheaper than more and more HD space. If you store and handle lots of backups, again tapes may become easier and cheaper to deal with than other media.
I have a fairly high trust for the long term durability of tapes sitting around. Manufacturers test this stuff and will tell you about it, including cautions for temperature limits and so on. Do disk manufacturers give equivalent figures for removed drives?
For personal home use, I think that anything is better than nothing; a second HD is cheap and easy (especially if you aren't worried about things that would take both drives out at once, like overheating or fire). For professional use in an office or the like (even a home office), I'd trust tape more. The up-front costs are bigger, but the benefits can be substantial, and there are things that are far more convenient with tapes that are very important for professional use (such as periodic offsite backups).
If you trust tapes they can also be used for archival purposes (where you delete the data off the HD after storing it on tape and verifying the tape) as well as normal backups. Depending on how much call you have for this, this may also represent a money savings with tape over disks.
I think there's perhaps two questions being asked: how to become a competent sysadmin, and how to get hired doing the job. They've got different answers; some people have been answering one, some people have been answering the other.
In order to be a good, competent sysadmin I think you need to understand Unix and the Unix philosophy. Once you grok the philosophy, it is much easier to predict and use Unix, because things make sense. The best book for this that I've ever read is Kernighan and Pike's The Unix Programming Environment. As a side benefit, it will teach you a good amount about the basic tools. It is somewhat dated and assumes that you can program.
Get experience on multiple different Unix variants. This will teach a number of valuable things: how things are different, how things are the same, and how to efficiently ferret out information on new things. Try to work on Unixes that vary as widely as possible, for maximum broadening. If you have a network, use it and work out how to manage several different Unixes so that the users (even if that's only you) won't notice and won't care which one they're using.
Learn debugging skills: how to rapidly figure out what exactly is going wrong in a broken thing and how to dive in to tweak it so it works again. I don't know of any good books on this (and it's probably only taught implicitly at your local university), but it is a skill that a sysadmin will use over and over again. Learn how to poke through a system to see how it does a particular thing.
Learn how to program if at all possible. Not just writing scripts, but really programming. I think that in the long run all the interesting and sustainable bits of system administration will involve being able to do so. Sooner or later all the easy stuff will be automated or become grunt-work of filling in forms or changing backup tapes, done by people who are essentially clerks.
In my opinion, good sysadmins don't know everything, but they do know how to find it out; they learn fast and they can ferret out that little necessary tidbit of information. Learn how to find things out on Unix systems; man pages, GNU texinfo, whatever local proprietary system a Unix vendor may have added, and so on. Information, especially on a Unix system, has a structure; grok it, exploit it, and predict it.
Learn how to read manual pages (an underrated but essential skill). When you can read the 7th Edition sh manpage and it makes sense, you have achieved this. (You can find the 7th Edition documentation at this URL.)
For getting hired, I have no really good ideas. If you know people in Human Resources departments (or who otherwise hire or filter people), ask them for what they look for in a resume that gets that first foot in the door. This may well be a certificate or a course, even if it doesn't teach you anything useful in the long term. HR often works on magic words.
A local Unix user's group may be a good way to get contacts, and maybe even get offered that first job; if nothing else, you can establish to the people who may hire you someday that you do indeed know what you're talking about. If there isn't a local Unix user's group, founding one is likely to get you fairly well known.