Linux-Consulting.com/AutomatedAdmin
|
|
| Purpose |
- Minimize System Admin costs
- Keep the production Systems as close to identical as possible
- Have a test farm of 3-5 system of each (distro) production server
- One SystemAdmin should be able to maintain 100 or 500 or 1000 servers and desktops w/ equal ease
- excludes "user questions/tech support"
|
| Automated SystemAdmin Methodology |
- SystemAdmin manually maintains a test farm of servers
- Test farm consists of clonable/replicatable 1-2 servers from cdrom of each distribution in production
- After testing the new updates, the patches are released to the distribution servers
- The automated scripts on the production servers update itself automatically
|
| Automated Admins Distribution Server |
- Security Patches for various linux distro
- Most non-security-admins apply security patches blindly or non-at-atll
- Anti-Spam Filters
- Gonna become an ongoing problem
- Production or Office environment Creating Thousands of (near)Identical Servers
- Test your releases before distribution
- Cannot manually maintain hundreds or n-thousand servers
- Field Service of Released/Sold Products at Customer Sites
- Very expensive to fly people around the country/world for updates
|
| Building Servers and Clients |
- Install a machine from a known common CDROM
- Apply any distro patches and harden the server/clients
- Apply any "in-house" working environment patches
- Fix home directories
- Fix FileSystem hierarchy
- Add in-house apps
- Add to daily, weekly, monthly backup strategy
|
| Update Process and Proceedure |
- Minimize System Admin to a handful of machines ( one-per distro version )
- Secure Distribution Servers ( same concept as Debian's Servers )
- Testing Servers BEFORE releasing patches
- Differences in Linux Distro
- Pathname are different
- Filenames are different
- Some apps and programs are missing
- Networks are NON-homogenious
- Linux, MS-Windoze, Sun, SGI,
- When to update itself
- Run update from cron
- Multiple Update.patches.txt files
- Default MasterServer files: everybody sync's against it
- Local Update.patches file for just one or two files it cares about
- Some files like user passwd or removed users should be passed around once an hour
- Other files ( new incoming user changes ) can be sync'd once a day
- Send email to users of the severity of the differences ( upgrade or not )
- Sometimes users do NOT want a changing-state machine...but a known-fixed state
- it can just check for differences ( for severity of differences )
- you can define it to automatically update if severity > xx
- Update unconditionally, if the distro server says to do so... ( serious bug found )
- If the Server is working... leave it alone ??
- Update yourself from 100 patchlevels before -- or --
go to a new cdrom and apply only 2 patches
- Allows users to do their work and not worry about "system admin issues"
|
| Server Differences and Patch Levels |
- Not All servers are "truely" identical
- DNS, Firewalls, HomeDir, WebServer, EmailServer, ...
- Some daemons are running, others are not
- Servers does NOT have to be at the same patch level
- If the server is working.. leave it alone ??
- Machines Constantly Morphs
- Servers start out as high-end WebServers and becomes low-end DNS servers
- Servers start out as high-end EmailServers and becomes user workstations
- Servers start out as user PCs and becomes backup servers with lots of disks
- Some test servers goes to productions before its time
- Parts are taken out and moved around
- Servers vs Clients
- Same files are configured differently for Servers vs Clients
- Firewalls
- DNS Servers
- /etc/resolv.conf, /etc/named.conf
- HomeDir and FileServers
- /etc/auto.Master, /etc/auto.home, /etc/passwd, /etc/aliases, /etc/exports
- Print Servers
- Samba FileServers
- /etc/samba/smb.conf, /etc/exports
- Users Workstations
- people will download and install various software everywhere
|
