Warning Livedoc is no longer being updated and will be deprecated shortly. Please refer to https://documentation.tjhsst.edu.

Discussion Agenda archive 1

From Livedoc - The Documentation Repository
Revision as of 05:32, 12 March 2007 by Brandon Vargo (talk | contribs) (Penguins as VM servers)
Jump to: navigation, search

If there is anything that needs to be/should be discussed in a sysadmin meeting, please list it here - also, if you add something to a topic, remember to add your username to the section:

Passwords/Access

  William,
  Remind me on Monday to talk about passwords/access in TA -- clearly we need to be able to login when 
  stuff breaks (like the network connection, or auth, both of which have happened in the past week), but 
  there were reasons we moved away from widespread access (people changing stuff without notice or log) 
  which we still need to address.
  Thanks,
  Mr. Torbert

==CSL keytabs (why not?)== --wyang

==Weekly Meetings== --bvargo, srepetsk

  • Whether it is possible to restart the weekly meetings, and if so, when they will take place
    • Weekly Meetings will be replaced by TA meetings every Monday.

==Re-deploy Penguins as VM Servers== --bvargo

  • Specifically, the penguins
  • In order to host VM environments for the 23 TA people, where each person has one VM for I2, and one VM for web, we need lots and lots of ram and disk space
    • 2GB of ram can hold just about all of the I2 VMs, along with a shared mysql VM
    • In order to do web services, it depends on what people want to install, which can be big on both memory and disk space
  • 7 new machines work great for applications that need more CPU power, but they only have 512MB of ram (at least number the one I have played with does, along with a 1.7GHz Celeron)
  • Use of penguins (one or more) as VM servers relieve several problems
    • Provide disk space that can be used for:
      • Shared VM storage
      • Storage of images to netboot new servers, some of which do not have disks
    • Add more ram into the pool for use by VMs
      • Each penguin has 2GB of ram, most of which is currently unused
  • All services the penguins currently host (not many) can be moved to VMs
    • King
      • Mirror
        • Already on sol, although it could be moved to a VM, but there is no need unless there is a reason it can't stay on sol
      • Workstation imaging server (includes netboot and TFTP server)
        • Can easily be moved to a VM, it just needs storage
    • Robustus
      • Oldremote
        • This really should go to a VM, so we don't have an entire server stuck on a legacy authentication mechanism
        • Eventually, once multi-realm works, the need for oldremote will go away anyways
    • Emperor
      • Tape backups
        • Can move to another server
        • Can stay on emperor, and not be in a VM
        • Can be put into a VM, and the tape drive allocated to that VM (no live migration though)
      • Iodine-dev
        • Already moving to VMs

==Service Distribution== --bvargo

  • specifically what services, if any, will go onto the "new" servers

==Future of Livedoc== --bvargo

  • Update software
    • latest version of mediawiki
    • move to something more structured (like twiki, or something similiar)
  • If we move to something more structured, it should have a WYSIWYG editor - I (bvargo for one, would update livedoc a lot more if it was more structured, and had a WYSIWYG editor in it (most of the WYSIWYG editors for mediawiki have had security issues, so I would steer clear of them)

==Virtualization ideas== --bvargo, wyang

  • What services to start to virtualize, as a proof of concept and/or permanent installation*
    • Dev hosts - each developer gets their own host to setup and configure as they wish for whatever they are doing (currently being implemented on humboldt for iodine developemnt, as well as development of the new school website)
    • remote and oldremote (until it goes away) - separate configuration for each, without needing to commit a workstation or server to that configuration - also prevents users from gaining access to production servers
    • DNS - bind has not had a great security record, it would be best to put bind in an isolated environment, making a vm perfect - if this is not going to be done for awhile, bind should at least be chrooted
    • etc
  • Data storage methods to employ for virtualization
    • Central storage on one or more servers, provides HA (something like storage arrays with both data and VMs)
    • Distributed storage, using something like AoE
    • Local storage with backup - vm is stored locally, with another copy somewhere else that is updated periodically, but is not turned on unless needed
    • Some other storage scheme

==Cleanup of AFS== --bvargo

  • While we are auditing AFS permissions, and removing @local.tjhsst.edu users, we should do a few other things
  • Clean the service directory
    • Archive everything that is no longer in use
    • Archive everything that is no longer useful
  • Audit permissions on all directories, including web, etc
  • Other cleanup tasks (I'll add more when I have more time)

==Security issues== --bvargo

  • Separation of services
    • Services should be separated for security, if one is compromised, all services should not be compromised
      • fiordland comes to mind as something that should be fixed
      • One solution is to put services into virtual machines - good security, with additional management benefits - want to move what host a service runs on, just move the vm with a simple command
  • Logging - do we look at the logs for anything anymore, and if not, how can we go about accomplishing this, so we know what is happening on our systems
  • More issues added as I have more time to add them to this list

==High availability / load balancing== --bvargo, srepetsk

  • Currently we have almost zero high availability for most services, this needs to change - also, we need to test high availability functions for services in which it supposedly should work
  • Mysql
  • Apache
  • Kerberos (does it work?)
  • Iodine
  • Remote and oldremote (until it goes away) - loadbalanced and high availability
  • Workstation service ip, so I can ssh to workstation, and it will redirect me to the workstation with the lowest load?
  • Zimbra (can we make it work, even though the "community" edition does not include it)
  • Load balancing for LTSP - login to "LTSP" or something, and have it redirect you to either "Rockhopper" or "Bottom"
  • Other services

==Rack Configuration== --bvargo

  • Find a place for the 7 "new" servers we just received
  • Find a place for the machines sitting behind the rack (tess and alpha)
  • Organize machines by machine type (e.g. the penguins together, the hp's together, the new hp's together, the 7 1u servers together)?
  • Relabel machines because most are incorrect, due to the new ip scheme (the labels have the old ip addresses)

==Backups== --bvargo, srepetsk

  • Off-site backup -- possibly in the room outside the library, or the closet in the guys locker room that's used for the PA system (I think) srepetsk
  • Online backups for AFS (yesterday directory)
  • Offline backups for AFS, how it is implemented, and what we have to do to get it to work (following emperor's troubles)

==Additional "services" to offer in the lab== --bvargo, srepetsk, wyang

  • Yesterday directory for all home directories
  • Postgresql
  • Bugzilla or TRAC for issues users encounter in the lab
  • Form submission on tjhsst.edu/admin/ or tjhsst.edu/syslab or papers on the wall for web accounts, mysql stuff, etc. (talk to lkearsle)

==Stuff that needs to be fixed== --bvargo

  • Yesterday directory on old afs directories (stopped working at the start of February)
  • Timely processing of user service request form - Do we need a new system for handling these requests (see online form submission in the services section above)?
  • The workstation agammemnon should be agamemnon, someone misspelled when typing in the hostname

Lost and Found

srepetsk, bvargo

  • At this time, I (srepetsk) think there are currently two options
    • Start our own lost and found so we have a place to put all the random stuff sitting around the lab
      • There is currently a lost and found of sorts hidden in the bookshelf by the systems monitor --bvargo
    • Take all the stuff in the lab "lost and found" and take it down to the lost and found by the security office

==SCT/Old Rockhopper== --srepetsk

  • SCT/Old Rockhopper
    • We currently have no use for these two old servers, as the processors in them are 333MHz
    • Both are taking up space in the lab - one on the floor, one on a desk that could be moved out
  • I would also like to address the carts:
    • The cart with the two old Macs
    • The smaller gray cart with the random junk on it
    • The cart with the UPS batteries (batteries could be moved into the back of the admin closet
  • All the other random junk laying around on the floor, etc.

==Enable Dynamic Power Savings Mode on Intel HPs== --wyang

  • Note to Lee: I have had no bad experiences with laptop power savings features (from an ancient P1 Toshiba to a 1-2 yr old IBM) and I was unable to find any problems online (either with laptops or with HP's) after a quick Google search. Please provide some links. FYI it is OS-independent.
  • HP's website

==IPv6== --bvargo

  • Currently, all machines (unless they don't support it, or are otherwise disabled) on our csl network (even vpn users) have ipv6 addresses (actually two of them, a link address and a global address) - apparently our router hands out the network prefix, thus hosts are able to generate the remaining 64bits of the address based off the mac address, if a mac address is not available, the address is automatically generated each time the link comes up.
    • Does anyone know how the router is configured - the only thing that I know is that the addresses are Abilene intranet2 addresses, and that the router magically responds to ipv6 requests to give hosts these addresses
    • To test to see if a host is using ipv6, goto http://www.kame.net/ - if the turtle is dancing (i.e. animated), then you are using ipv6 to connect to their web server
  • Do we want to put ipv6 addresses in DNS, so that most traffic in the lab is running over ipv6? The only AAAA record that we currently have is for ns1, so dns lookups over ipv6 work. This would work for all "hardware" addresses, as they are the same every time the link comes up, but DDNS would have to be used to update DNS each time a link with an autogenerated address comes up (or we just statically configure all links that are not associated with a MAC).
  • Should we make ipv6 addresses for service ips?
  • Do we want to give new vm's ipv6 addresses?
  • Is the firewall protecting our ipv6 addresses, in addition to the ipv4 addresses?