[in reply to my previous email on Enigma]
> Options:
>
> - 6 disks w/ no spare (90GB)
> - 6 disks w/ non hot spare (90GB) [need to purchase extra disk]
> - 5 disks w/ hot spare (72GB)
It looks like we'll go for 6 disks with a cold spare (which we'll need to buy
at some stage, the system disk from Enigma would be a prime candidate to fail
given its usage :)
> 2. Filesystems
>
> Draft:
>
> / 100MB Small root okay for BSD. Current disk usage on
> enigma is due to crap in /root which will be in
> /local/admin in new setup instead..
>
> swap 512MB or 1GB At least equal to total memory, worth allowing
> for future expansion (e.g. 1GB). [current swap
> on enigma is at 256MB]
I think we should go for the 1GB, it may be underutilised now, but it's easier
to create now then 1 or 2 years down the road when/if we upgrade RAM.
> /usr 4GB Separate root and usr also okay with BSD ;)
> 4GB should be sufficient for software and
> /usr/{src,obj}.
Might bump this to 5 or 6GB, just give us some more breathing room.
> /var 4GB Should be sufficient.
This will be bumped to the remaining disk space to accomodate [web]mail (i.e.
/var/mail/<Maildirs>). This way we enforce the use of disk space on enigma for
mail only. If we were to use $HOME/Maildir, users could use enigma for home
storage which would "compete" with their mail. rb-radio will go under /var
somwhere as it'll be the biggest partition (greedy music lovers!)
> /local 2GB Similar to that on prodigy (promotes
> consistency). Not as big though, note: not
> *really* an essential f/s but handy to have.
>
> /home ~78GB [or 60GB] Size depends on 6 [or 5] disk array.
Home quota will be set at 1Mb. Size will be reduced to 4GB (a rough estimate
of 2000 users * 1MB + 100 users * 20MB). Quotas can of course be increased on
a per-user request basis if necessary (e.g. they're doing project/devel work
etc.) That's the 100 users above.
> /tmp 64MB Use UFS, MFS or md?
Any opinions as to which option?
> /var/tmp 128MB Make bigger (512MB/1GB) if no "/scratch" f/s:
>
> /scratch ? GB Single disk or a possible vinum setup..
>
> Quotas will be in force on /home and nosuid, nodev. Main data to be kept in
> /local & /var. All filesystems to have soft updates enabled. Also, as of
> 4.4-S the new dirprefs and dirhash code (both on by default) will result in
> better layout & performance for the new filesystems.
Just wondering how the defaults in newfs are for (large) filesystems?
Especially if /var will be geared towards Maildir usage (think lots & lots of
inode usage). *goes off to read tuning(7)*
> Secondly, unified logins should really be implemented (regardless of giving
> all users a login or not) ideally with LDAP (has been proposed before) as
> this has many other benefits (e.g. mailman, nntpcache, Cyrus, etc.). This
> should work even when prodigy is down (i.e. use replication). The hack
> alternative is to copy the prodigy /etc/{passwd,shadow} files across
> (securely) daily, merge into a master.passwd format, run pwd_mkdb, etc. and
> possibly also prevent local password/finger info changes. Nanny (back on
> the network now) can be used for testing this without borking prodigy :)
A thought occurred to me - OpenLDAP can be configured to use /etc/passwd as
it's "database" (read-only AFAIR). I haven't checked yet, but does anyone know
off-hand if this setup can provide authentication? This would make LDAP
authentication and name lookups etc. available, but leave password
administration as-is (read: less work involved). If it doesn't, an alternative
would be to build the database from the passwd file on a regular basis, making
sure to include the crypted password. There's no reason why we couldn't
migrate completely to LDAP, however this approach means we don't have to
modify our user admin software (read: admins are lazy).
--
Cillian
