[techtalk] Multiple passwd lists ?
Has anyone managed a passwd and shadow list with more the 10,000 people on it? Is there a way to possibly divide the passwd/shadow lists into smaller multiple files? Something like passwd.master shadow.master, passwd.domainname1, shadow.domainname1, passwd.domainname2, and shadow.domainname2? Thanks, Beverly ___ techtalk mailing list [EMAIL PROTECTED] http://www.linux.org.uk/mailman/listinfo/techtalk
Re: [techtalk] Multiple passwd lists ?
On Fri, Dec 01, 2000 at 08:20:54AM -0500, Beverly Guillermo wrote: > Has anyone managed a passwd and shadow list with more the 10,000 people > on it? Is there a way to possibly divide the passwd/shadow lists into > smaller multiple files? Something like passwd.master shadow.master, > passwd.domainname1, shadow.domainname1, passwd.domainname2, and > shadow.domainname2? I would recommend using an ldap server as authentication source and the pam_ldap module to authenticate against ldap. > Thanks, > Beverly -- Live long and prosper - Harald Welte / [EMAIL PROTECTED]http://www.gnumonks.org GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*) ___ techtalk mailing list [EMAIL PROTECTED] http://www.linux.org.uk/mailman/listinfo/techtalk
Re: [techtalk] Multiple passwd lists ?
Beverly Guillermo: > Has anyone managed a passwd and shadow list with more the 10,000 people > on it? Is there a way to possibly divide the passwd/shadow lists into > smaller multiple files? Something like passwd.master shadow.master, > passwd.domainname1, shadow.domainname1, passwd.domainname2, and > shadow.domainname2? At my Uni we had passwd.$OS (because Linux, FreeBSD, Solaris, Irix etc had different system users and -shells so the files were different even though the passwords were the sa,e) in rdist and passwd.user in a special pwdist program someone had written. passwd.user was generated from the central userdatabase. There was a daemon on the dist-server receiving updates from the userdatabase, and then commands were run to check if this was an old/excisting user, create homedir etc, and to add a line to passwd.user. Then pwdist ran every 15 minutes and copied (with scp) the passwd.user to the clients. There it was added with passwd.$OS to /etc/passwd and /etc/shadow. This has run for about 4 years now, so I guess it works ok. But I think I would have experimented a bit with LDAP if I was you. I have been looking at it a bit and I think it may be a good solution for you. Magni :) -- sash is very good for you. ___ techtalk mailing list [EMAIL PROTECTED] http://www.linux.org.uk/mailman/listinfo/techtalk
Re: [techtalk] Multiple passwd lists ?
From: Beverly Guillermo <[EMAIL PROTECTED]> > Has anyone managed a passwd and shadow list with more the 10,000 people > on it? Is there a way to possibly divide the passwd/shadow lists into > smaller multiple files? Something like passwd.master shadow.master, > passwd.domainname1, shadow.domainname1, passwd.domainname2, and > shadow.domainname2? Thousands of years ago I tested it with that many users, but I've not done anything of that sort recently. Mostly because I no longer maintain Shadow ;-( You should be able to use "mkpasswd" on all of the shadow-related files to create DBM files. Other than performance there is no technical reason why you couldn't have 10,000 entries in your /etc/passwd and /etc/shadow files. -- Julie. ___ techtalk mailing list [EMAIL PROTECTED] http://www.linux.org.uk/mailman/listinfo/techtalk
Re: [techtalk] Multiple passwd lists ?
Magni Onsoien: > Beverly Guillermo: > > Has anyone managed a passwd and shadow list with more the 10,000 people > > on it? Is there a way to possibly divide the passwd/shadow lists into > > smaller multiple files? Something like passwd.master shadow.master, > > passwd.domainname1, shadow.domainname1, passwd.domainname2, and > > shadow.domainname2? > > At my Uni we had passwd.$OS (because Linux, FreeBSD, Solaris, Irix etc > had different system users and -shells so the files were different even > though the passwords were the sa,e) in rdist and passwd.user in a special > pwdist program someone had written. passwd.user was generated from the > central userdatabase. There was a daemon on the dist-server receiving > updates from the userdatabase, and then commands were run to check if > this was an old/excisting user, create homedir etc, and to add a line to > passwd.user. Then pwdist ran every 15 minutes and copied (with scp) the > passwd.user to the clients. There it was added with passwd.$OS to > /etc/passwd and /etc/shadow. This has run for about 4 years now, so I > guess it works ok. Uhm, I kind of forgot to say that we have about 20,000 users on the system. With an updated OS (i.e. not RedHat 5.2), it's not a problem. The performance problems we experiences were due to too many entries in a directory (specifically /home/stud/$USER), so the home directory structure was changed to /home/home$raid_nr/us/user which works fine. Magni :) -- sash is very good for you. ___ techtalk mailing list [EMAIL PROTECTED] http://www.linux.org.uk/mailman/listinfo/techtalk
[techtalk] RE:backup newbie
>Message: 12 >Date: Wed, 29 Nov 2000 18:40:27 -0800 (PST) >From: Eric Richard Turner <[EMAIL PROTECTED]> >To: Conor Daly <[EMAIL PROTECTED]> >cc: [EMAIL PROTECTED] >Subject: Re: [techtalk] RE: backup newbie >On Wed, 29 Nov 2000, Conor Daly wrote: > but can I do the following? > > 1st of Month: Full backup > Sunday:Differential Backup from Monthly > Daily: Differential Backup from Sunday > >Good question. I suspect it depends on the backup utility and/or operating >system. I know that NTBACKUP on Windows NT uses the archive bit on each >file. During a full-system backup it clears the archive bit on all files. >When a file is changed, the archive bit is set. Differential and >incremental backups save only those files for which the archive bit is >set. The difference between the two is that during differential backups, >the archive bit is not cleared whereas during incremental backups the >archive bit is cleared. >So, using NTBACKUP on Windows NT, the answer to your question is no. >However, it seems reasonable that one could write a backup utility that >would catalogue when each file has been saved, perhaps using a checksum, >CRC or last-modified date to determine when a file has been modified. Then >the backup utility could do all sorts of interesting backup scenarios >based on the combination of the catalogue and the list of modified files. >Whether or not this sort of thing exists is beyond the scope of my >experience. I've never had to set up incremental or differential backups >for Linux, so I'm not sure what can and cannot be done. I recently >received the latest Linux Journal, which has an article in it about >automated backups in Linux. Now I'm curious, so I guess I'll just have to >read it :-)>>> >Eric R. Turner I'm not sure that's completely correct; with Linux's dump, for instance, you specify the level of the backup (0-9) when creating an incremental backup, so it's not neccesarily what's changed since the day before. With dump, as with many archive utilities, , the difference between an incremental and differential backup is that a differential backs up everything changed since the last FULL BACKUP, whereas an incremental backs up everything changed since the most recent lower-number backup. So, a differential would look like this: Sun-full backup Mon-All files changed since sunday Tue-All files changed since sunday (note: this will be re-backing up some files that were backed up monday; that's the disadvantage to differentials) Wed-All files changed since sunday etc... A simple incremental would look like this: Sun-level 0 (full backup) Mon-level 1 (all files changed since sun) Tue-level 2 (all files changed since mon) etc... The disadvantage here is that if things go boom, you need the last full backup and all incremental backups since then. If this were to happen the day before you did a full backup, that's a lot of tapes! Now with a differential, you would only need the last full backup, and the last differential backup, MUCH easier to deal with. However, differentials are not very efficient; many files are being backed up every day. (NOTE: a differential is really an incremental with one day being a level 0 backup, and all other days being level 1's) Now if you've got a large server environment, or someplace where most of your files change often, you might consider doing a more "clever" incremental backup system, as follows: Once a month (sunday)-level 0 Once a week (sunday) - level 1 Daily schedule - mon-level 3 tue-level 2 wed-level 5 thu-level 4 fri-level 7 sat-level 6 This is called the "towers of hanoi" method, and is, from what I've read, the most efficient system for doing backups (I believe this is what Conor was referring to, though I admit I've never implemented it). In this case, most files are backed up twice but only twice, so it's a nice compromise between a differential and a simple incremental. On the downside, it still requires you to have more than 2 tape sets in the event of a complete restore. On another note, one thing that I think confuses a lot of people is that different pieces of software use the words "incremental" and "differential" to mean different things. I've defined them as I have because I believe that's how most Linux utilities I'm aware of define them; however, a novell backup utility I'm running (Arcserve) defines differential the same way, but incremental as what I've described as a "simple" incremental above. And I've heard that some utilities switch the terms around altogether :(. In my company, we don't have too much to backup (~250G), and we have access to a 22 tape DLT jukebox, so I opted to go for ease-of-restore over efficiency-of-backup, and I use a differential system using archive bits (you can also usually do differentials by date). I hate to repeat myself, as I've said this in previous posts, but I will anyway ;-): O'reilly's "Unix
Re: [techtalk] RE:backup newbie
On Fri, 1 Dec 2000, Brian Sweeney wrote: > > >Good question. I suspect it depends on the backup utility and/or operating > >system. I know that NTBACKUP on Windows NT uses the archive bit on each > >file. During a full-system backup it clears the archive bit on all files. > >When a file is changed, the archive bit is set. Differential and > >incremental backups save only those files for which the archive bit is > >set. The difference between the two is that during differential backups, > >the archive bit is not cleared whereas during incremental backups the > >archive bit is cleared. > >So, using NTBACKUP on Windows NT, the answer to your question is no. > >However, it seems reasonable that one could write a backup utility that > >would catalogue when each file has been saved, perhaps using a checksum, > >CRC or last-modified date to determine when a file has been modified. Then > >the backup utility could do all sorts of interesting backup scenarios > >based on the combination of the catalogue and the list of modified files. > >Whether or not this sort of thing exists is beyond the scope of my > >experience. I've never had to set up incremental or differential backups > >for Linux, so I'm not sure what can and cannot be done. I recently > >received the latest Linux Journal, which has an article in it about > >automated backups in Linux. Now I'm curious, so I guess I'll just have to > >read it :-)>>> > > I'm not sure that's completely correct; with Linux's dump, for instance, you > specify the level of the backup (0-9) when creating an incremental backup, > so it's not neccesarily what's changed since the day before. Since I've never had to implement backups under Linux, my example was NT. Linux is a completely different animal! With NT and the NTBACKUP command, what I wrote is correct. The NT BACKUP utility uses the archive bit on files to determine which files need to be backed up. Each time a file is modified, the archive bit is set so that the backup utility will back up the file. During the next backup, if the backup is an incremental then the archive bit is cleared so that the file doesn't automatically get backed up each during subsequent backup. If the backup is differential then the archive bit is NOT cleared so that the file keeps getting backed up everytime until the next full-system backup (at which point all files' archive bits are cleared). >With dump, as > with many archive utilities, , the difference between an incremental and > differential backup is that a differential backs up everything changed since > the last FULL BACKUP, whereas an incremental backs up everything changed > since the most recent lower-number backup. So, a differential would look > like this: Yes, this agrees with my definition of incremental and differential, except that NT doesn't have options for various levels: it's all or none! Yet another case for the superiority of Linux as a server OS *grin*. -- My public OpenPGP key can be found at http://www.wwu.edu/~turnere/turnere.asc ___ techtalk mailing list [EMAIL PROTECTED] http://www.linux.org.uk/mailman/listinfo/techtalk
