1. Weaknesses in current setup

  1. Need separate root account, for which we need to log in to issue commands
  2. ALL admin has to be done by root (i.e. Mark and Robert) whereas we'd like to give individuals access (yum, cdrecord,...)
  3. Logs, cronjob output etc currently gets mailed to a user called logmail @xena. Why not email to Mark and Robert?
  4. Backups need manual restarting after reboot.
  5. Each root account homedir has its own contents. Need central place for scripts.
  6. Security: firewalls anyone?
  7. Security: users should change passwords occasionally; should also be prevented from accidentally mucking up systems.
  8. Put mail aliases on NIS (root -> Robert & Mark).

  9. Local admin scripts should go on a network folder, and if necessary should only allow themselves to execute on a given computer.
  10. Which computers are special/servers? Should .profile give them exported names?

  11. All local folders (localdata and export) must have rwx permissions and network folders must be in separate partitions (/opt and /home).

  12. Printing: user access to kill print jobs (soln: sudo access to lpadmin via printgod user).
  13. Make /scratch access invisible wrt multiple hosts (wilma and yvette)
  14. Enable gnome-ask-pass for all users on login?

  15. Any services we want to expose outside, like samba?
  16. User-initiated backups of e.g. local data?
  17. Tea and coffee songs!
  18. Local job control - to suspend jobs of CPU hogs, with notification.
  19. distscript for all e.g. to find free CPUs.

  20. Share package download cache to reduce bandwidth demand.

Cluster wishlist (?):

  1. No change to user programs.
  2. Head node detects slave failure and restarts jobs.
  3. Auto install of nodes.
  4. Scheduling: no more than one "heavy" process per CPU.

2. Network plans

2.1. Move to Debian

We are not moving to Debian. Fedora Core 5 looks OK (although not particularly stylish...) and yum looks quite good for updating.

Debian is not that different. The main changes are apt (which we're using already), a few configuration files in different places and a few commands which are different (like update-rc.d instead of chkconfig). I'm not fully committed to this idea, but it is something to think about.

2.2. NIS

Although NIS and NFS are insecure, I'm not suggesting changing this. We can be quite comfortable with the degree of security over the physical infrastructure available in the department.

A general note: I've removed all FQDNs from hostnames in configuration files for CUPS and a few other things. This means that if the FQDN changes, the only thing that must be tweaked is /etc/hosts on xena, as well as perhaps the /etc/hosts on each machine (which only contains xena and callista).

I just think it might be a good idea to record our important NIS settings.

Other authentications:

2.3. NFS

Same here: record settings.

2.4. Firewall

Firewall is currently not enabled and needs to be. Shorewall is good for this. Essentially allow anything out, and allow anything in if it is part of an established connection. Oh, and allow pyro in on SSH.

One important thing to bear in mind for firewalling is if we use a wiki for the group webpages. Then we'll have some internal pages on which we might want to put secret information. This will be easier if we can guarantee that no outsiders can view our internal copy of the webpages.

2.5. Additional packages and /opt

The main thing preventing a change of distro is familiarity with what is available at freshrpms, and it might be worth knowing what is there that we are using. A little software audit might be a good idea. Also, we should clean the attic on /opt.

2.6. Sudo-ing admin

It is slightly daft that only root users can access things like CD writers on our machines at the moment. And it is also better admin practice. Example file at http://www.courtesan.com/sudo/sample.sudoers, showing it's not too difficult to write. Doesn't natively work with NIS, though, so we might need an /opt/etc or rdist it. {{{# # Sample /etc/sudoers file. # # This file MUST be edited with the 'visudo' command as root. # # See the sudoers man page for the details on how to write a sudoers file. #

# User alias specification

User_Alias FULLTIMERS = robert,marklee User_Alias PARTTIMERS = tomh,andreas #User_Alias WEBMASTERS = will, wendy, wim

# Runas alias specification

Runas_Alias OP = root Runas_Alias WEB = apache

# Host alias specification

Host_Alias 64BIT = attila,bella,callista,dolores,elizabeth,florence:\

Host_Alias KBGSUBNET = 172.17.41.0/255.255.255.0 Host_Alias NISSERVERS = xena,callista Host_Alias DVDWRITER = dolores,elizabeth

# Cmnd alias specification

Cmnd_Alias UPDATE = /usr/bin/yum Cmnd_Alias BURNDVD = /usr/bin/growisofs Cmnd_Alias KILL = /usr/bin/kill Cmnd_Alias NICE = /usr/bin/nice Cmnd_Alias PRINTING = /usr/sbin/lpc, /usr/bin/lprm Cmnd_Alias SU = /usr/bin/su Cmnd_Alias VIPW = /usr/sbin/vipw, /usr/bin/passwd, /usr/bin/chsh, \

# Override built-in defaults

Defaults syslog=auth Defaults:FULLTIMERS !lecture Defaults:millert !authenticate Defaults@SERVERS log_year, logfile=/var/log/sudo.log

# User specification

# root and users in group wheel can run anything on any machine as any user root ALL = (ALL) ALL %wheel ALL = (ALL) ALL

# full time sysadmins can run anything on any machine without a password FULLTIMERS ALL = NOPASSWD: ALL

# part time sysadmins may run anything but need a password PARTTIMERS ALL = ALL

# jack may run anything on machines in CSNETS jack CSNETS = ALL

# lisa may run any command on any host in CUNETS (a class B network) lisa CUNETS = ALL

# operator may run maintenance commands and anything in /usr/oper/bin/ operator ALL = DUMPS, KILL, PRINTING, SHUTDOWN, HALT, REBOOT,\

# joe may su only to operator joe ALL = /usr/bin/su operator

# pete may change passwords for anyone but root on the hp snakes pete HPPA = /usr/bin/passwd [A-z]*, !/usr/bin/passwd root

# bob may run anything on the sparc and sgi machines as any user # listed in the Runas_Alias "OP" (ie: root and operator) bob SPARC = (OP) ALL : SGI = (OP) ALL

# jim may run anything on machines in the biglab netgroup jim +biglab = ALL

# users in the secretaries netgroup need to help manage the printers # as well as add and remove users +secretaries ALL = PRINTING, /usr/bin/adduser, /usr/bin/rmuser

# fred can run commands as oracle or sybase without a password fred ALL = (DB) NOPASSWD: ALL

# on the alphas, john may su to anyone but root and flags are not allowed john ALPHA = /usr/bin/su [!-]*, !/usr/bin/su *root*

# jen can run anything on all machines except the ones # in the "SERVERS" Host_Alias jen ALL, !SERVERS = ALL

# jill can run any commands in the directory /usr/bin/, except for # those in the SU and SHELLS aliases. jill SERVERS = /usr/bin/, !SU, !SHELLS

# steve can run any command in the directory /usr/local/op_commands/ # as user operator. steve CSNETS = (operator) /usr/local/op_commands/

# matt needs to be able to kill things on his workstation when # they get hung. matt valkyrie = KILL

# users in the WEBMASTERS User_Alias (will, wendy, and wim) # may run any command as user www (which owns the web pages) # or simply su to www. WEBMASTERS www = (www) ALL, (root) /usr/bin/su www

# anyone can mount/unmount a cd-rom on the machines in the CDROM alias ALL CDROM = NOPASSWD: /sbin/umount /CDROM,\

2.7. Backups

These should be done with passwordless ssh. I believe. I don't think someone should have to manually start it up. Perhaps if we set up a cron job that checked whether the backups were working, and emailed someone if they weren't. Also organise HFS backup.

2.8. Updating mechanism

The choices are apt, yum or rhn. Should enable a network folder with the download cache to reduce bandwidth demand.

The hands-down choice is yum. Yum is mature and is catered for by vast repositories. Apt is no longer an option in Fedora, so sticking with apt would entail changing distro - and RHN was always a non-starter. It would be a good idea to record on the internal group webpage when each machine updates.

I've set up a mirrorlist at http://xena/static/yummirrorlist.

2.9. Printing

CUPS is fairly decent, but we need a way to give users control over the print queue. Making one admin account available to all on the CUPS server is an OK solution. Another is to make lpadmin a sudo-able command. This has the advantage of being recorded in the log files, so that we can shout at people for cancelling others' print jobs.

I would like to know more about the Allow,Deny goodie in cupsd.conf, which seems highly problematic to me. At one stage we had tried to do Allow from 10.10.41.* and it bombed, which is silly.

2.10. Group website as a wiki

This is fairly easy to set up, and also quite easy to clone an existing design. To be done. The site is hosted on xena (this link will only work if you're on the KBG network) and we're intending a cron job will do a dump to HTML and then ssh it over to the webserver. Need passwordless ssh key for this.

2.11. Other

Need to write a script that suspends any job that is hogging CPU/memory, and possibly also one to nice jobs. This must be available to all users through sudo.

Need to figure out where important (crit, alert, emerg) log messages get emailed. Should enable one log server and set up sendmail on that. The email only needs to reach the physics server, so that shouldn't be too tough. Might want to set up Splunk to make searching log files easier.

Useful scripts (like distscript that performs the same command on each host in the network) should be put in /opt. That includes the suspend-job script mentioned above. Note that jobs that can only run on a particular server - like the backup script - can then be told to test if they're running on the wrong server. We should have a file called /opt/etc/networklayout which has stuff like {{{BACKUPSERVER="wendy" FILESERVER="callista" NISMASTER="xena" NISSLAVES="callista " ADMINEMAIL="bill@example.com"}}}

Should we ask for a minimum level of password security from users? Or perhaps ask them to change password every few months?

Enable gnome-ask-pass on all users' login, so that their sshing becomes passwordless automatically.

Do we want to offer a SAMBA mount to the outside world?

Tea and coffee songs

Script yourself out of a job!

KBGroup (last edited 2008-01-06 23:30:29 by localhost)