(note: i asked this a few days ago but it *appears* that that post was tossed due to getting excessive bounces from my account. so i'm posting it again, apologies if you're seeing it a second time.)
over the next several weeks, i'm teaching some courses in RHEL admin but (unsurprisingly) i'll be using centos 5.5. it's a decently-written, 3rd party course, all the generic, standard admin topics but it does leave me about a 1/2 day to throw in any cool stuff i want to add.
so, any recommendations for neat things that people here have done in the way of what can be added to or configured on a centos server system? the course covers all the standard topics -- installation, package management, service management, filesystem maintenance, that sort of thing. so i'm looking for bonus, neat stuff that others here do as a matter of course when putting together a centos system.
logging utilities? intrusion detection? monitoring? anything that leaps to mind that i can use to fill up a few more hours. i'm already thinking of showing how to build and boot a new kernel. other ideas? thanks.
rday
On Fri, 2010-09-17 at 03:39 -0400, Robert P. J. Day wrote:
other ideas?
LTSP
On Fri, 17 Sep 2010, Frank Cox wrote:
On Fri, 2010-09-17 at 03:39 -0400, Robert P. J. Day wrote:
other ideas?
LTSP
an intriguing idea, but that might be a bit ambitious and might also cut into future marketing. one of my plans is that, after this week-long course is over, i want to market to the same client some quick, 1-day courses that go further and each cover a very specific topic.
for example, i can imagine a 1-day course in virtualization. maybe a 1-day course in server security. a course in monitoring and system tuning. and perhaps a course in advanced networking that would incorporate LTSP.
so i'm more looking for ideas that are nice add-ons to the generic course, but that don't jump so far ahead that they might take a bite out of a future course that i could market.
rday
Hi,
On Fri, 2010-09-17 at 03:39 -0400, Robert P. J. Day wrote:
other ideas?
Maybe a crash course in troubleshooting using the rescue CD ?
I don't know exactly which subjects are covered in your course ? Can you be more precise ? :)
regards,
Michel
On Fri, 17 Sep 2010, Michel van Deventer wrote:
Hi,
On Fri, 2010-09-17 at 03:39 -0400, Robert P. J. Day wrote:
other ideas?
Maybe a crash course in troubleshooting using the rescue CD ?
I don't know exactly which subjects are covered in your course ? Can you be more precise ? :)
sure. while it's a 3rd-party courseware manual, it was obviously written to emulate fairly closely red hat's admin course here:
https://www.redhat.com/courses/rh131_red_hat_linux_system_administration/det...
so the best way i can sum it up is that it's a perfectly decent admin course that covers all the standard admin topics you'd expect to see. all i was interested in was any additional packages or configuration that people on this list have used to great effect that most people would *not* have thought of or heard of.
for instance, is anyone version controlling their system config files with a utility like, say, "etckeeper"? that sort of thing. i just want to pad out some of the sections with a few more items.
rday
On Fri, 17 Sep 2010, Robert P. J. Day wrote:
To: CentOS discussion list centos@centos.org From: Robert P. J. Day rpjday@crashcourse.ca Subject: [CentOS] looking for cool, post-install things to do on a centos 5.5 system
(note: i asked this a few days ago but it *appears* that that post was tossed due to getting excessive bounces from my account. so i'm posting it again, apologies if you're seeing it a second time.)
over the next several weeks, i'm teaching some courses in RHEL admin but (unsurprisingly) i'll be using centos 5.5. it's a decently-written, 3rd party course, all the generic, standard admin topics but it does leave me about a 1/2 day to throw in any cool stuff i want to add.
so, any recommendations for neat things that people here have done in the way of what can be added to or configured on a centos server system? the course covers all the standard topics -- installation, package management, service management, filesystem maintenance, that sort of thing. so i'm looking for bonus, neat stuff that others here do as a matter of course when putting together a centos system.
logging utilities? intrusion detection? monitoring? anything that leaps to mind that i can use to fill up a few more hours. i'm already thinking of showing how to build and boot a new kernel. other ideas? thanks.
Hi Robert. That sounds interesting. You might like to checkout my Auto Linux Installer bash scripts. I wrote these to automate the installation of Fedora and now have a set configured to install CentOS 5.5
You may be able to enhance your course and add some more time to it by using some things from my ALI scripts?
They are designed to install a fresh Fedora/CentOS/RHEL system, deal with automating service management, and configure the freshly installed system to use your saved configuration files - if there are any.
http://www.karsites.net/centos/anyuser/auto-linux-installer.php
I'm also 3/4 the way writing a tutorial on how to download and install the latest version of Eclipse 3.6.0 Helios for PHP programmers, on CentOS 5.5
I have it all working fine, but the howto is not completed yet.
HTH
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
On Fri, 2010-09-17 at 03:39 -0400, Robert P. J. Day wrote:
over the next several weeks, i'm teaching some courses in RHEL admin but (unsurprisingly) i'll be using centos 5.5. it's a decently-written, 3rd party course, all the generic, standard admin topics but it does leave me about a 1/2 day to throw in any cool stuff i want to add.
You should share some of the topics/courses here.
so, any recommendations for neat things that people here have done in the way of what can be added to or configured on a centos server system? the course covers all the standard topics -- installation, package management, service management, filesystem maintenance, that sort of thing. so i'm looking for bonus, neat stuff that others here do as a matter of course when putting together a centos system.
Serial over LAN or IPMI for the Fence Management on the machine. OOB Access.
logging utilities? intrusion detection? monitoring? anything that leaps to mind that i can use to fill up a few more hours. i'm already thinking of showing how to build and boot a new kernel. other ideas? thanks.
Explain how to set up auditd to enable full logging.
John
over the next several weeks, i'm teaching some courses in RHEL admin but (unsurprisingly) i'll be using centos 5.5. it's a decently-written, 3rd party course, all the generic, standard admin topics but it does leave me about a 1/2 day to throw in any cool stuff i want to add. so, any recommendations for neat things that people here have done
For me: I'd want to have a closer look at things that *might* give advantages but DO bring troubles: SEL KVM
And dangers such as DoS DDoS Zombie computers randomly port-scanning Internal user ignorance, apathy, malice, and mis-information about how to secure the campus network from the hostile world. A boss who does not understand what he wants, but he wants it real bad. ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
From: Robert P. J. Day rpjday@crashcourse.ca
so, any recommendations for neat things that people here have done in the way of what can be added to or configured on a centos server system? the course covers all the standard topics -- installation, package management, service management, filesystem maintenance, that sort of thing. so i'm looking for bonus, neat stuff that others here do as a matter of course when putting together a centos system.
Random thoughts (maybe already in your standard topics): - kickstart (cd, usb, pxe) - local CentOS repository - drbd or some distributed fs - nfs / nis - ldap - samba - keepalived / ipvs - fail2ban - proxies (squid, nginx...) - monitoring (nagios, cacti...) - VM (KVM, Xen...) - quotas, acls - encrypted fs
JD
On Fri, 17 Sep 2010, Robert P. J. Day wrote:
To: CentOS discussion list centos@centos.org From: Robert P. J. Day rpjday@crashcourse.ca Subject: [CentOS] looking for cool, post-install things to do on a centos 5.5 system
...
over the next several weeks, i'm teaching some courses in RHEL admin but (unsurprisingly) i'll be using centos 5.5. it's a decently-written, 3rd party course, all the generic, standard admin topics but it does leave me about a 1/2 day to throw in any cool stuff i want to add.
Adding Multimedia capabilities
Using SQLite3 from the command line Creating a Database Creating and populating a table Selecting, inserting, updating and deleting data in the database
Remote login sessions using ssh -X
Intro to nmap, nessus and Metasploit
Intro to Firefox plugins, eg Firebug How to find and install other usefull FF plugins.
Obviously the list is endless really.
HTH
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
On Fri, 17 Sep 2010, Keith Roberts wrote:
Adding Multimedia capabilities
Using SQLite3 from the command line Creating a Database Creating and populating a table Selecting, inserting, updating and deleting data in the database
Remote login sessions using ssh -X
Intro to nmap, nessus and Metasploit
Intro to Firefox plugins, eg Firebug How to find and install other usefull FF plugins.
Obviously the list is endless really.
not entirely. keep in mind that this is an *admin* course for RHEL/centos so any additional topics should be primarily server-oriented. that suggests that things like multimedia would have little value. heck, even graphical utilities might be irrelevant since, as a server, the system might not even have X installed.
so, yes, i realize this is still being a bit vague. i'm just interested in what others have found as being really, really useful in the context of setting up a server.
rday
--
======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA
Top-notch, inexpensive online Linux/OSS/kernel courses http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On Fri, Sep 17, 2010 at 9:39 AM, Robert P. J. Day rpjday@crashcourse.ca wrote:
logging utilities? intrusion detection? monitoring? anything that leaps to mind that i can use to fill up a few more hours. i'm already thinking of showing how to build and boot a new kernel. other ideas? thanks.
sysadmins should now really know about configuration management tools. So show them how to bootstrap an infrastructure with kickstart and cfengine (or puppet or chef or ...)
On 9/17/10 2:39 AM, Robert P. J. Day wrote:
(note: i asked this a few days ago but it *appears* that that post was tossed due to getting excessive bounces from my account. so i'm posting it again, apologies if you're seeing it a second time.)
over the next several weeks, i'm teaching some courses in RHEL admin but (unsurprisingly) i'll be using centos 5.5. it's a decently-written, 3rd party course, all the generic, standard admin topics but it does leave me about a 1/2 day to throw in any cool stuff i want to add.
so, any recommendations for neat things that people here have done in the way of what can be added to or configured on a centos server system? the course covers all the standard topics -- installation, package management, service management, filesystem maintenance, that sort of thing. so i'm looking for bonus, neat stuff that others here do as a matter of course when putting together a centos system.
logging utilities? intrusion detection? monitoring? anything that leaps to mind that i can use to fill up a few more hours. i'm already thinking of showing how to build and boot a new kernel. other ideas? thanks.
I'd consider the most valuable things to know about would be the nature of an assortment of 3rd party yum repositories (i.e. EPEL makes an effort not to overwrite core packages but probably won't have everything you want), how to find and install their *-release packages, how to use yum to search and install things from them, and that most of them should left disabled in the yum configuration so they don't affect things unless you explicitly enable them on the command line for a search or specific package you want.
Oh - and how to install and use freenx/NX for remote access.
On Fri, 17 Sep 2010, Les Mikesell wrote:
I'd consider the most valuable things to know about would be the nature of an assortment of 3rd party yum repositories (i.e. EPEL makes an effort not to overwrite core packages but probably won't have everything you want), how to find and install their *-release packages, how to use yum to search and install things from them, and that most of them should left disabled in the yum configuration so they don't affect things unless you explicitly enable them on the command line for a search or specific package you want.
i've already added a section on EPEL, just so i can install things like git. and i know there's an entire page at centos.org on extra repos. any there that you *particularly* recommend? i'll revisit that page later today but i'm thinking that, for the sake of this first-level admin course, EPEL might be sufficient for now.
Oh - and how to install and use freenx/NX for remote access.
hmmmm ... good idea. or i might just add in VNC and carry over the freenx to an additional course dealing with networking/remote admin/etc. thanks.
rday
On 9/17/10 7:51 AM, Robert P. J. Day wrote:
On Fri, 17 Sep 2010, Les Mikesell wrote:
I'd consider the most valuable things to know about would be the nature of an assortment of 3rd party yum repositories (i.e. EPEL makes an effort not to overwrite core packages but probably won't have everything you want), how to find and install their *-release packages, how to use yum to search and install things from them, and that most of them should left disabled in the yum configuration so they don't affect things unless you explicitly enable them on the command line for a search or specific package you want.
i've already added a section on EPEL, just so i can install things like git. and i know there's an entire page at centos.org on extra repos. any there that you *particularly* recommend? i'll revisit that page later today but i'm thinking that, for the sake of this first-level admin course, EPEL might be sufficient for now.
No, the important thing to know is that the repositories that have the current packages you want to install will also cause dependency issues if you enable them for general updates. I use rpmforge for subversion and some other things, but I haven't really kept up with what is out there.
Oh - and how to install and use freenx/NX for remote access.
hmmmm ... good idea. or i might just add in VNC and carry over the freenx to an additional course dealing with networking/remote admin/etc. thanks.
I'd guess that for most people starting with linux, freenx with NX running on their existing windows/mac would be a much better fit. Maybe vmwware player or virtualbox too.
On 9/17/2010 8:18 AM, Les Mikesell wrote:
hmmmm ... good idea. or i might just add in VNC and carry over thefreenx to an additional course dealing with networking/remote admin/etc. thanks.
I'd guess that for most people starting with linux, freenx with NX running on their existing windows/mac would be a much better fit. Maybe vmwware player or virtualbox too.
Oh, another thing - I've always thought that every course on unix-like systems should touch on what the fork() and open() system calls do, sort of like learning to count to 10 before memorizing math formulas. If you understand that every process except init is fork()ed from a running parent, that environment variables and open files are inherited (because the child/parent share the COW memory), and the security checks that happen in open(), you can pretty much deduce the rest of the system behavior (well, except for selinux...).
On Fri, Sep 17, 2010 at 08:18:38AM -0500, Les Mikesell wrote:
On 9/17/10 7:51 AM, Robert P. J. Day wrote:
On Fri, 17 Sep 2010, Les Mikesell wrote:
Oh - and how to install and use freenx/NX for remote access.
hmmmm ... good idea. or i might just add in VNC and carry over the freenx to an additional course dealing with networking/remote admin/etc. thanks.
I'd guess that for most people starting with linux, freenx with NX running on their existing windows/mac would be a much better fit. Maybe vmwware player or virtualbox too.
And then, you can give them one of the more important Linux lessons. Let them install FreeNX, go to the website and see the completely outdated docmentation. Learning how horrible so much of the documentation is, is probably an important part of being a Linux administrator. FreeNX, fortunately, has a CentOS wiki article, so let them google for it.
Not even being sarcastic here. Lack of good docoumentation is probably one of the biggest challenges facing the Linux user or administrator.
Scott Robbins wrote:
On Fri, Sep 17, 2010 at 08:18:38AM -0500, Les Mikesell wrote:
On 9/17/10 7:51 AM, Robert P. J. Day wrote:
On Fri, 17 Sep 2010, Les Mikesell wrote:
Oh - and how to install and use freenx/NX for remote access.
hmmmm ... good idea. or i might just add in VNC and carry over the freenx to an additional course dealing with networking/remote admin/etc. thanks.
I'd guess that for most people starting with linux, freenx with NX running on their existing windows/mac would be a much better fit.
Maybe vmwware
player or virtualbox too.
And then, you can give them one of the more important Linux lessons. Let them install FreeNX, go to the website and see the completely outdated docmentation. Learning how horrible so much of the documentation is, is probably an important part of being a Linux administrator. FreeNX, fortunately, has a CentOS wiki article, so let them google for it.
Not even being sarcastic here. Lack of good docoumentation is probably one of the biggest challenges facing the Linux user or administrator.
Hey, you're being easy on them. Have them install and configure openLDAP, and find the documentation....
mark
On Fri, Sep 17, 2010 at 03:18:23PM -0400, m.roth@5-cent.us wrote:
Scott Robbins wrote:
Oh - and how to install and use freenx/NX for remote access.
And then, you can give them one of the more important Linux lessons. Let them install FreeNX, go to the website and see the completely outdated docmentation. Learning how horrible so much of the documentation is, is probably an important part of being a Linux administrator. FreeNX, fortunately, has a CentOS wiki article, so let them google for it.
Not even being sarcastic here. Lack of good docoumentation is probably one of the biggest challenges facing the Linux user or administrator.
Hey, you're being easy on them. Have them install and configure openLDAP, and find the documentation....
Heh--well, since I've written my own page on it, it's gotten better. RH didn't help by making some undocumented changes, but once again, the CentOS folks got it documented.
I suspect LDAP documentation is one reason Active Directory became so popular. (Feed the troll, I'm hungry.) :)
(Although the part about LDAP documentation is not trolling, I think it's pretty much an accepted thing. The Active Directory part was, of course, a troll.)
Scott Robbins wrote:
On Fri, Sep 17, 2010 at 03:18:23PM -0400, m.roth@5-cent.us wrote:
Scott Robbins wrote:
<snip>
Oh - and how to install and use freenx/NX for remote access.
And then, you can give them one of the more important Linux lessons. Let them install FreeNX, go to the website and see the completely outdated docmentation. Learning how horrible so much of the documentation is, is probably an important part of being a Linux administrator. FreeNX, fortunately, has a CentOS wiki article, so let them google for it.
Not even being sarcastic here. Lack of good docoumentation is probably one of the biggest challenges facing the Linux user or
administrator.
Hey, you're being easy on them. Have them install and configure openLDAP, and find the documentation....
Heh--well, since I've written my own page on it, it's gotten better. RH didn't help by making some undocumented changes, but once again, the CentOS folks got it documented.
I did have some notes, but dunno if I ever emailed 'em to myself from my job in '06, but though it took me about a month, I managed to get it up, with the help of a dozen or so links, after wading through dozens of links, and lots of folks begging for help (and not getting any), and *way* outdated stuff....
I suspect LDAP documentation is one reason Active Directory became so popular. (Feed the troll, I'm hungry.) :)
Dunno. It was up there already. But then, M$$$ would make sure of that.
(Although the part about LDAP documentation is not trolling, I think it's pretty much an accepted thing. The Active Directory part was, of course, a troll.)
And their utterly inadequate tools.
mark
On Fri, Sep 17, 2010 at 03:34:58PM -0400, m.roth@5-cent.us wrote:
Scott Robbins wrote:
Heh--well, since I've written my own page on it, it's gotten better. RH didn't help by making some undocumented changes, but once again, the CentOS folks got it documented.
I did have some notes, but dunno if I ever emailed 'em to myself from my job in '06, but though it took me about a month, I managed to get it up, with the help of a dozen or so links, after wading through dozens of links, and lots of folks begging for help (and not getting any), and *way* outdated stuff....
That's basically what I did--wrote up my notes and put up the page that I wished I'd had when first trying to wrap my head around it. Like many opensource things, it's not as hard as it seems, once you realize how it's done.
(Although the part about LDAP documentation is not trolling, I think it's pretty much an accepted thing. The Active Directory part was, of course, a troll.)
And their utterly inadequate tools.
LDAP's, or AD's? Our Windows admin teaches mixed martial arts as a sideline, so I don't argue too much with him. :)
All kidding aside, to the OP, though it's not a cool thing--it's one of the crummy things in many cases--finding docs to supplement the often inadequate official documentation is pretty durn important.
Scott Robbins wrote:
On Fri, Sep 17, 2010 at 03:34:58PM -0400, m.roth@5-cent.us wrote:
Scott Robbins wrote:
<snip>
And their utterly inadequate tools.
LDAP's, or AD's? Our Windows admin teaches mixed martial arts as a sideline, so I don't argue too much with him. :)
openLDAP.
All kidding aside, to the OP, though it's not a cool thing--it's one of the crummy things in many cases--finding docs to supplement the often inadequate official documentation is pretty durn important.
Yup.
mark
On 9/17/2010 3:01 PM, Scott Robbins wrote:
And their utterly inadequate tools.
LDAP's, or AD's? Our Windows admin teaches mixed martial arts as a sideline, so I don't argue too much with him. :)
All kidding aside, to the OP, though it's not a cool thing--it's one of the crummy things in many cases--finding docs to supplement the often inadequate official documentation is pretty durn important.
Is there any distribution (or even a VM image) that comes with LDAP working out of the box for local and samba authentication and ready to replicate to others? I think ClearOS has it for a single install but the last I looked the replication wasn't working yet.
On September 17, 2010 01:14:42 pm Les Mikesell wrote:
Is there any distribution (or even a VM image) that comes with LDAP working out of the box for local and samba authentication and ready to replicate to others? I think ClearOS has it for a single install but the last I looked the replication wasn't working yet.
Would be nice. Man that was a pain to get working.
On 9/17/2010 2:07 PM, Scott Robbins wrote:
Oh - and how to install and use freenx/NX for remote access.
hmmmm ... good idea. or i might just add in VNC and carry over thefreenx to an additional course dealing with networking/remote admin/etc. thanks.
I'd guess that for most people starting with linux, freenx with NX running on their existing windows/mac would be a much better fit. Maybe vmwware player or virtualbox too.
And then, you can give them one of the more important Linux lessons. Let them install FreeNX, go to the website and see the completely outdated docmentation. Learning how horrible so much of the documentation is, is probably an important part of being a Linux administrator. FreeNX, fortunately, has a CentOS wiki article, so let them google for it.
Not even being sarcastic here. Lack of good docoumentation is probably one of the biggest challenges facing the Linux user or administrator.
I sort-of agree, but having a working display is the one thing you need most in order to do anything else at all - and doing it via freenx often lets you park your session on a fast remote server instead of the slow inherited desktop you are likely to use for experimentation otherwise, so I'd make an exception and do some handholding here. It's in epel now so I'd get it from there via yum instead of the centos-testing version. And then you can ssh in to the server with putty or whatever client you like to cat /etc/nxserver/client.id_dsa.key. Copy/paste that into the key dialog in your local NX config, save it and you are ready to go faster than you can find the first page of incorrect details with google. And if you have more than one person doing it, they can share the same box with user level logins and learn to coordinate their root changes.
On Fri, 17 Sep 2010, Robert P. J. Day wrote:
i've already added a section on EPEL, just so i can install things like git. and i know there's an entire page at centos.org on extra repos. any there that you *particularly* recommend? i'll revisit that page later today but i'm thinking that, for the sake of this first-level admin course, EPEL might be sufficient for now.
How to identify and work your way out of rpm conflicts. (without using nodeps of course).
---------------------------------------------------------------------- Jim Wildman, CISSP, RHCE jim@rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine
On Fri, 17 Sep 2010, Jim Wildman wrote:
On Fri, 17 Sep 2010, Robert P. J. Day wrote:
i've already added a section on EPEL, just so i can install things like git. and i know there's an entire page at centos.org on extra repos. any there that you *particularly* recommend? i'll revisit that page later today but i'm thinking that, for the sake of this first-level admin course, EPEL might be sufficient for now.
How to identify and work your way out of rpm conflicts. (without using nodeps of course).
i've already added some of that, using things like --replacepkgs and --replacefiles and so on.
rday
--
======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA
Top-notch, inexpensive online Linux/OSS/kernel courses http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On 9/17/2010 12:58 PM, Robert P. J. Day wrote:
On Fri, 17 Sep 2010, Jim Wildman wrote:
On Fri, 17 Sep 2010, Robert P. J. Day wrote:
i've already added a section on EPEL, just so i can install things like git. and i know there's an entire page at centos.org on extra repos. any there that you *particularly* recommend? i'll revisit that page later today but i'm thinking that, for the sake of this first-level admin course, EPEL might be sufficient for now.
How to identify and work your way out of rpm conflicts. (without using nodeps of course).
i've already added some of that, using things like --replacepkgs and --replacefiles and so on.
I think a current moderately harmless example would be getting a non-ancient version of subversion and viewvc from rpmforge, then noting that a 'yum full update' with epel enabled will swap in a viewvc configured in an incompatible way.
On Fri, 17 Sep 2010, Jim Wildman wrote:
To: CentOS mailing list centos@centos.org From: Jim Wildman jim@rossberry.com Subject: Re: [CentOS] looking for cool, post-install things to do on a centos 5.5 system
On Fri, 17 Sep 2010, Robert P. J. Day wrote:
i've already added a section on EPEL, just so i can install things like git. and i know there's an entire page at centos.org on extra repos. any there that you *particularly* recommend? i'll revisit that page later today but i'm thinking that, for the sake of this first-level admin course, EPEL might be sufficient for now.
How to identify and work your way out of rpm conflicts. (without using nodeps of course).
How to download, md5sum check, unpack, configure and compile a GPL *.tar.gz package.
As SysAdmin that's something they will need to do sooner or later :)
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
On 9/17/2010 1:06 PM, Keith Roberts wrote:
i've already added a section on EPEL, just so i can install things like git. and i know there's an entire page at centos.org on extra repos. any there that you *particularly* recommend? i'll revisit that page later today but i'm thinking that, for the sake of this first-level admin course, EPEL might be sufficient for now.
How to identify and work your way out of rpm conflicts. (without using nodeps of course).
How to download, md5sum check, unpack, configure and compile a GPL *.tar.gz package.
As SysAdmin that's something they will need to do sooner or later :)
But it's much more important to know all the reasons *not* to do that except as a last resort. Reasons that someone who has had to maintain and update such things for decades will know that won't occur to an inexperienced beginner. You can summarize by saying "yum update is a lot easier".
On Fri, 17 Sep 2010, Les Mikesell wrote:
To: centos@centos.org From: Les Mikesell lesmikesell@gmail.com Subject: Re: [CentOS] looking for cool, post-install things to do on a centos 5.5 system
On 9/17/2010 1:06 PM, Keith Roberts wrote:
i've already added a section on EPEL, just so i can install things like git. and i know there's an entire page at centos.org on extra repos. any there that you *particularly* recommend? i'll revisit that page later today but i'm thinking that, for the sake of this first-level admin course, EPEL might be sufficient for now.
How to identify and work your way out of rpm conflicts. (without using nodeps of course).
How to download, md5sum check, unpack, configure and compile a GPL *.tar.gz package.
As SysAdmin that's something they will need to do sooner or later :)
But it's much more important to know all the reasons *not* to do that except as a last resort. Reasons that someone who has had to maintain and update such things for decades will know that won't occur to an inexperienced beginner. You can summarize by saying "yum update is a lot easier".
Of course.
But what if they want/need to install a package that is not available in any of the repos? Maybe even just for testing purposes?
Keith
On 9/17/2010 1:21 PM, Keith Roberts wrote:
How to download, md5sum check, unpack, configure and compile a GPL *.tar.gz package.
As SysAdmin that's something they will need to do sooner or later :)
But it's much more important to know all the reasons *not* to do that except as a last resort. Reasons that someone who has had to maintain and update such things for decades will know that won't occur to an inexperienced beginner. You can summarize by saying "yum update is a lot easier".
Of course.
But what if they want/need to install a package that is not available in any of the repos? Maybe even just for testing purposes?
Yes, that's where the 'last resort' comes in... But you are right, you should also know how to build things that live in /usr/local or under your home directory. Sometimes there are special purpose needs for things that don't exist as rpms yet or you need concurrent access to different versions. And I'm sure someone will add that you should also know how to build your own rpm if I don't mention it, but that can be non-trivial compared to just staying out of the way of the system-managed space.
On Fri, 17 Sep 2010, Les Mikesell wrote:
To: centos@centos.org From: Les Mikesell lesmikesell@gmail.com Subject: Re: [CentOS] looking for cool, post-install things to do on a centos 5.5 system
On 9/17/2010 1:21 PM, Keith Roberts wrote:
How to download, md5sum check, unpack, configure and compile a GPL *.tar.gz package.
As SysAdmin that's something they will need to do sooner or later :)
But it's much more important to know all the reasons *not* to do that except as a last resort. Reasons that someone who has had to maintain and update such things for decades will know that won't occur to an inexperienced beginner. You can summarize by saying "yum update is a lot easier".
Of course.
But what if they want/need to install a package that is not available in any of the repos? Maybe even just for testing purposes?
Yes, that's where the 'last resort' comes in... But you are right, you should also know how to build things that live in /usr/local or under your home directory. Sometimes there are special purpose needs for things that don't exist as rpms yet or you need concurrent access to different versions. And I'm sure someone will add that you should also know how to build your own rpm if I don't mention it, but that can be non-trivial compared to just staying out of the way of the system-managed space.
That's almost getting into repository management. I've looked at this rpm guide:
http://www.rpm.org/max-rpm-snapshot/
I found this very helpfull in understanding how to use RPM, and it also goes into details about creating rpm packages.
Regards,
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
Les Mikesell wrote:
On 9/17/2010 1:06 PM, Keith Roberts wrote:
<snip>
How to download, md5sum check, unpack, configure and compile a GPL *.tar.gz package.
As SysAdmin that's something they will need to do sooner or later :)
But it's much more important to know all the reasons *not* to do that except as a last resort. Reasons that someone who has had to maintain and update such things for decades will know that won't occur to an inexperienced beginner. You can summarize by saying "yum update is a lot easier".
Excerpt when a user comes to you and asks you to install a package for which there isn't any rpm... or, for that matter, when you're force to use CPAN to install a module for which there's no .rpm, and then the build fails, but works if you cd into /root/.cpan/BUILD/<pgmsource> and make....
mark
On 9/17/2010 2:15 PM, m.roth@5-cent.us wrote:
How to download, md5sum check, unpack, configure and compile a GPL *.tar.gz package.
As SysAdmin that's something they will need to do sooner or later :)
But it's much more important to know all the reasons *not* to do that except as a last resort. Reasons that someone who has had to maintain and update such things for decades will know that won't occur to an inexperienced beginner. You can summarize by saying "yum update is a lot easier".
Excerpt when a user comes to you and asks you to install a package for which there isn't any rpm... or, for that matter, when you're force to use CPAN to install a module for which there's no .rpm, and then the build fails, but works if you cd into /root/.cpan/BUILD/<pgmsource> and make....
Agreed that it's good to know how - but 'there isn't any rpm' should really mean there isn't any rpm at any well-maintained location, not just in the base system or that you didn't bother to look. Every time you build something yourself you are taking on the job of maintaining it forever and probably leaving people in a lurch when you leave and someone else has to figure out what non-standard things you did.
On Fri, 17 Sep 2010, Les Mikesell wrote:
Agreed that it's good to know how - but 'there isn't any rpm' should really mean there isn't any rpm at any well-maintained location, not just in the base system or that you didn't bother to look. Every time you build something yourself you are taking on the job of maintaining it forever and probably leaving people in a lurch when you leave and someone else has to figure out what non-standard things you did.
i agree with this. i'm looking for extra goodies that don't involve possibly violating corporate IT policy by downloading and building new packages to be installed on mission-critical servers. there are certainly enough existing packages at trustworthy repos that i don't need to go beyond that.
rday
Les Mikesell wrote:
On 9/17/2010 2:15 PM, m.roth@5-cent.us wrote:
How to download, md5sum check, unpack, configure and compile a GPL *.tar.gz package.
As SysAdmin that's something they will need to do sooner or later :)
But it's much more important to know all the reasons *not* to do that except as a last resort. Reasons that someone who has had to maintain and update such things for decades will know that won't occur to an inexperienced beginner. You can summarize by saying "yum update is a lot easier".
Excerpt when a user comes to you and asks you to install a package for which there isn't any rpm... or, for that matter, when you're force to use CPAN to install a module for which there's no .rpm, and then the build fails, but works if you cd into /root/.cpan/BUILD/<pgmsource> and make....
Agreed that it's good to know how - but 'there isn't any rpm' should really mean there isn't any rpm at any well-maintained location, not just in the base system or that you didn't bother to look. Every time you build something yourself you are taking on the job of maintaining it forever and probably leaving people in a lurch when you leave and someone else has to figure out what non-standard things you did.
Um, no. Sometimes users want stuff that no one *has* built a package for, and I'm certainly not going to. Perhaps you work in a more structured environment, where all the servers are the same. Ain't the case in a lot of places I've worked, and certainly not here (here being where I work now, and who I ->may not<- imply that I speak for, contract regs, federal regs...).
And, of course, you'd *better* document what you did and how you did it, and put that in a well-known location, such as the organization's wiki....
mark
On 9/17/2010 3:08 PM, m.roth@5-cent.us wrote:
Agreed that it's good to know how - but 'there isn't any rpm' should really mean there isn't any rpm at any well-maintained location, not just in the base system or that you didn't bother to look. Every time you build something yourself you are taking on the job of maintaining it forever and probably leaving people in a lurch when you leave and someone else has to figure out what non-standard things you did.
Um, no. Sometimes users want stuff that no one *has* built a package for, and I'm certainly not going to. Perhaps you work in a more structured environment, where all the servers are the same. Ain't the case in a lot of places I've worked, and certainly not here (here being where I work now, and who I ->may not<- imply that I speak for, contract regs, federal regs...).
And, of course, you'd *better* document what you did and how you did it, and put that in a well-known location, such as the organization's wiki....
All I'm saying is that it often turns out to be a whole lot more work than the initial 'configure, make, make install', so you either have to train the users to do their own copies in their own space so it will scale, or be very careful about how much of this you take on. And I'm saying this from experience. It's not much different from writing your own code where the initial cut is about 10% of the work of maintaining it - and if the upstream project goes away or takes a direction not compatible with your use, that's where you end up anyway.
Les Mikesell wrote:
On 9/17/2010 3:08 PM, m.roth@5-cent.us wrote:
Agreed that it's good to know how - but 'there isn't any rpm' should really mean there isn't any rpm at any well-maintained location, not just in the base system or that you didn't bother to look. Every time you build something yourself you are taking on the job of maintaining it forever and probably leaving people in a lurch when you leave and someone else has to figure out what non-standard things you did.
Um, no. Sometimes users want stuff that no one *has* built a package for, and I'm certainly not going to. Perhaps you work in a more structured environment, where all the servers are the same. Ain't the case in a lot of places I've worked, and certainly not here (here being where I work now, and who I ->may not<- imply that I speak for, contract regs, federal regs...).
And, of course, you'd *better* document what you did and how you did it, and put that in a well-known location, such as the organization's wiki....
All I'm saying is that it often turns out to be a whole lot more work than the initial 'configure, make, make install', so you either have to train the users to do their own copies in their own space so it will scale, or be very careful about how much of this you take on. And I'm saying this from experience. It's not much different from writing your own code where the initial cut is about 10% of the work of maintaining it - and if the upstream project goes away or takes a direction not compatible with your use, that's where you end up anyway.
Having spent far more of my career as a software person, let me say that what I've installed not from rpms or other packages has been nowhere near as much work as writing it... esp. when you factor in creature feep, er, feature creep, and "oh, I meant this, not *that*...."
mark
On 9/17/2010 3:30 PM, m.roth@5-cent.us wrote:
All I'm saying is that it often turns out to be a whole lot more work than the initial 'configure, make, make install', so you either have to train the users to do their own copies in their own space so it will scale, or be very careful about how much of this you take on. And I'm saying this from experience. It's not much different from writing your own code where the initial cut is about 10% of the work of maintaining it - and if the upstream project goes away or takes a direction not compatible with your use, that's where you end up anyway.
Having spent far more of my career as a software person, let me say that what I've installed not from rpms or other packages has been nowhere near as much work as writing it... esp. when you factor in creature feep, er, feature creep, and "oh, I meant this, not *that*...."
I think it is pretty hard to draw a line between code and custom configuration and what you have to do to keep them working as other things change. For example I once ran smail with some custom tweaks to work with binary attachments from a proprietary (AT&T) PC mail program and uucp. And some glue between that, hylafax, and a custom print spooler. They were, ummm, non-trivial to keep working over a period of several years, especially when smail sort of disappeared. But that was back before there were packaged versions of much of anything and you couldn't even count on updates to compile. The code that I controlled directly wasn't quite the same kind of problem.
If you have different users needing these things on the same machine you must at least have run into situations where someone needs one version of a CPAN module or a new php/python/mysql version when at the same time someone else is running something that won't work with it.
You might have run into the CPAN issue if you installed something like RT in the Centos 4 era.
Les Mikesell wrote:
On 9/17/2010 3:30 PM, m.roth@5-cent.us wrote:
All I'm saying is that it often turns out to be a whole lot more work than the initial 'configure, make, make install', so you either have to train the users to do their own copies in their own space so it will scale, or be very careful about how much of this you take on. And I'm saying this from experience. It's not much different from writing your own code where the initial cut is about 10% of the work of maintaining it - and if the upstream project goes away or takes a direction not compatible with your use, that's where you end up anyway.
Having spent far more of my career as a software person, let me say that what I've installed not from rpms or other packages has been nowhere near as much work as writing it... esp. when you factor in creature
feep, er,
feature creep, and "oh, I meant this, not *that*...."
I think it is pretty hard to draw a line between code and custom configuration and what you have to do to keep them working as other things change. For example I once ran smail with some custom tweaks to
My experience has been different. When I'm working as a developer, it's *all* development. When I've installed some software for someone, it may be a pita to install, but then I only once in a while have to go through that again, and the next time, I know most of the things that need doing. Not something to take up most of my week. <snip>
If you have different users needing these things on the same machine you
Um, no. Our users, or teams, each have a number of servers: dev, test and prod. <snip>
You might have run into the CPAN issue if you installed something like RT in the Centos 4 era.
Ugh. When I was with AT&T, 3-4 years ago, we looked at RT, and blew it off for Mantis, which was *much* easier to work with.
Hmmm, or was there some other project management software I installed. <shrug> It's been a few years, and I ain't there with notes.
mark
Les Mikesell wrote:
On 9/17/2010 3:30 PM, m.roth@5-cent.us wrote:
All I'm saying is that it often turns out to be a whole lot more work than the initial 'configure, make, make install', so you either have to train the users to do their own copies in their own space so it will
<snip>
If you have different users needing these things on the same machine you must at least have run into situations where someone needs one version of a CPAN module or a new php/python/mysql version when at the same time someone else is running something that won't work with it.
You might have run into the CPAN issue if you installed something like RT in the Centos 4 era.
Actually, my manager just laid something on me this morning: the new release of Adobe's 64-bit flash for Linux. I suppose I need to get it from Adobe, then find who's running 64 bit and not 32 bit....
mark
On Fri, 17 Sep 2010, m.roth@5-cent.us wrote:
To: CentOS mailing list centos@centos.org From: m.roth@5-cent.us Subject: [CentOS] Was: Re: looking for cool, post-install things, is custom software
Les Mikesell wrote:
On 9/17/2010 3:30 PM, m.roth@5-cent.us wrote:
All I'm saying is that it often turns out to be a whole lot more work than the initial 'configure, make, make install', so you either have to train the users to do their own copies in their own space so it will
<snip> > If you have different users needing these things on the same machine you > must at least have run into situations where someone needs one version > of a CPAN module or a new php/python/mysql version when at the same time > someone else is running something that won't work with it. > > You might have run into the CPAN issue if you installed something like > RT in the Centos 4 era.
Actually, my manager just laid something on me this morning: the new release of Adobe's 64-bit flash for Linux. I suppose I need to get it from Adobe, then find who's running 64 bit and not 32 bit....
Can you find that out via TCP/IP, or not ?
Keith
On 9/17/2010 4:32 PM, Keith Roberts wrote:
Actually, my manager just laid something on me this morning: the new release of Adobe's 64-bit flash for Linux. I suppose I need to get it from Adobe, then find who's running 64 bit and not 32 bit....
Can you find that out via TCP/IP, or not ?
'ssh host uname -i' - but that might not be enough. What is supposed to happen if you have a 64 bit machine but run a 32 bit browser? It doesn't look like their yum setup autodetects but it should at least work for the 32 bit side.
Keith Roberts wrote:
On Fri, 17 Sep 2010, m.roth@5-cent.us wrote:
From: m.roth@5-cent.us Les Mikesell wrote:
On 9/17/2010 3:30 PM, m.roth@5-cent.us wrote:
<snip>
Actually, my manager just laid something on me this morning: the new release of Adobe's 64-bit flash for Linux. I suppose I need to get it from Adobe, then find who's running 64 bit and not 32 bit....
Can you find that out via TCP/IP, or not ?
Nahhh, I'll start out with a script we have that lets me send a command to all, what, nearly 200 machines we administer. I figure the command will be something like "rpm -qa | grep slash | grep 64", though I may have to look at the format flag for rpm to force it to give the architecture.
mark
On Fri, 17 Sep 2010, m.roth@5-cent.us wrote:
Actually, my manager just laid something on me this morning: the new release of Adobe's 64-bit flash for Linux. I suppose I need to get it from Adobe, then find who's running 64 bit and not 32 bit....
On 64 bit, the [manual] install was as simply as moving a backstop copy of the old module to one side for testing, and manually positioning the new .so at:
/usr/lib64/mozilla/plugins
and restarting Firefox ... I've not packaged it up yet
-- Russ herrold
[herrold@centos-5 plugins]$ pwd ; ls -al ; uname -a /usr/lib64/mozilla/plugins total 19760 drwxr-xr-x 2 root root 4096 Sep 16 10:45 . drwxr-xr-x 4 root root 4096 Sep 8 12:39 .. -rw-r--r-- 1 root root 10601968 Sep 16 10:45 libflashplayer.so -rwxr-xr-x 1 root root 9570952 Dec 30 2009 libflashplayer.so-OLD Linux centos-5.first.lan 2.6.18-194.11.3.el5xen #1 SMP Mon Aug 30 16:55:32 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux [herrold@centos-5 plugins]$
On Fri, Sep 17, 2010 at 06:06:56PM -0400, R P Herrold wrote:
On Fri, 17 Sep 2010, m.roth@5-cent.us wrote:
Actually, my manager just laid something on me this morning: the new release of Adobe's 64-bit flash for Linux. I suppose I need to get it from Adobe, then find who's running 64 bit and not 32 bit....
On 64 bit, the [manual] install was as simply as moving a backstop copy of the old module to one side for testing, and manually positioning the new .so at:
/usr/lib64/mozilla/plugins
and restarting Firefox ... I've not packaged it up yet
Russ' method worked for me as well. I should add, for opera users, opera looks first in /usr/lib/opera/plugins, but I changed the order in opera's menu (get to advanced and content) and all was good.
On Fri, 17 Sep 2010, Les Mikesell wrote:
Agreed that it's good to know how - but 'there isn't any rpm' should really mean there isn't any rpm at any well-maintained location, not just in the base system or that you didn't bother to look. Every time you build something yourself you are taking on the job of maintaining it forever and probably leaving people in a lurch when you leave and someone else has to figure out what non-standard things you did.
I think you overstate the matter with a strawman that lacks mutuality of obligation ...
If a person (person X) is employed at site Y, and the folks responsible for that site Y are willing to pay person X forever to maintain content forever, perhaps there is a 'leave in the lurch' situation
If site Y was willing to pay for documentation to be produced as to how the site was installed, and how it might thereafter be maintained going forward, it is no longer: 'non-standard'
But, if site Y was not willing to open their purse, it sure seems to me that one cannot fairly somehow hold person X accountable with the 'guilting' as to: 'leave in the lurch' for entropy and the absence of knowledge of site Y on how to address it without person X
Site Y gets the union of: what a commons community will freely offer, whatever deliverables one has paid for, and what one is then willing a subsequent maintainer to pay for when/if entropy happens
but this thread has wandered far, far afield
-- Russ herrold
On 9/17/2010 3:36 PM, R P Herrold wrote:
Agreed that it's good to know how - but 'there isn't any rpm' should really mean there isn't any rpm at any well-maintained location, not just in the base system or that you didn't bother to look. Every time you build something yourself you are taking on the job of maintaining it forever and probably leaving people in a lurch when you leave and someone else has to figure out what non-standard things you did.
I think you overstate the matter with a strawman that lacks mutuality of obligation ...
If a person (person X) is employed at site Y, and the folks responsible for that site Y are willing to pay person X forever to maintain content forever, perhaps there is a 'leave in the lurch' situation
I'm commenting in the context of a new sysadmin and what they should be taught. My point is that just because there is a huge amount of free code available for downloading and the time it takes to run 'configure, make, make install' is trivial, it is not necessarily a good idea to do that every time anyone asks.
Maybe we should compare it to what happens when someone asks to have something new added to CentOS, and note that all of the same reasons for not doing that may (or admittedly may not) apply to doing it within a company. It's just something a beginner should think about.
i'm not ignoring all of the suggestions so far (i'm taking note of all of them) but as rp herrold suggests, a lot of this is getting pretty far afield, so let me drag this back on-topic.
i'm looking for cool things that can be added into a very generic 5-day course in basic RHEL (centos) administration that wouldn't normally be covered. i've provided the outline on which the 3rd party courseware is based -- it was written to mimic red hat's RH 131 course:
https://www.redhat.com/courses/rh131_red_hat_linux_system_administration/
so you can see what's already there, and i'm after cool tips, tricks and utilities that people who are long-time RHEL/centos admins have learned that they think are terrifically useful that i can sneak in as bonus content.
the caveat is that i don't want to add topics that would take longer than, say, a half day since i can always take a topic like that, extend it to a full-day course, and market it *separately*.
case in point: virtualization. the course already covers virtualization *very* briefly and i don't want to make that section any longer since i can easily see having a full-day course on that topic.
*possibly* the same thing with puppet or cfengine (both excellent suggestions). i'm thinking of at least demoing one or both and, depending on the interest, perhaps suggesting a full day course in enterprise-wide administration.
anyway, i appreciate all of the ideas so far, and i'm definitely going to use some of them. thanks muchly.
rday
p.s. one stupendously trivial idea i had was to give each student a cheap USB drive and use that as the vehicle for playing with filesystem utilities. with an $8 2G drive, i can demonstrate concepts like hotplugging, udev, LVM and so on, knowing i'll never risk the contents of the hard drive.
On Sat, Sep 18, 2010 at 5:06 AM, Robert P. J. Day rpjday@crashcourse.ca wrote:
p.s. one stupendously trivial idea i had was to give each student a cheap USB drive and use that as the vehicle for playing with filesystem utilities. with an $8 2G drive, i can demonstrate concepts like hotplugging, udev, LVM and so on, knowing i'll never risk the contents of the hard drive.
That reminds me of a sysadmin course where we set up minimal, console-only QEMU virtual machines with two virtual disks, and taught fdisk, mkfs, RAID, LVM and the like.
On Sat, 18 Sep 2010, Eduardo Grosclaude wrote:
On Sat, Sep 18, 2010 at 5:06 AM, Robert P. J. Day rpjday@crashcourse.ca wrote:
p.s. one stupendously trivial idea i had was to give each student a cheap USB drive and use that as the vehicle for playing with filesystem utilities. with an $8 2G drive, i can demonstrate concepts like hotplugging, udev, LVM and so on, knowing i'll never risk the contents of the hard drive.
That reminds me of a sysadmin course where we set up minimal, console-only QEMU virtual machines with two virtual disks, and taught fdisk, mkfs, RAID, LVM and the like.
interesting ... is this course publicly available? be fun to take a look at it.
rday
On Sat, Sep 18, 2010 at 10:11 AM, Robert P. J. Day rpjday@crashcourse.ca wrote:
On Sat, 18 Sep 2010, Eduardo Grosclaude wrote:
On Sat, Sep 18, 2010 at 5:06 AM, Robert P. J. Day rpjday@crashcourse.ca wrote:
p.s. one stupendously trivial idea i had was to give each student a cheap USB drive and use that as the vehicle for playing with filesystem utilities. with an $8 2G drive, i can demonstrate concepts like hotplugging, udev, LVM and so on, knowing i'll never risk the contents of the hard drive.
That reminds me of a sysadmin course where we set up minimal, console-only QEMU virtual machines with two virtual disks, and taught fdisk, mkfs, RAID, LVM and the like.
interesting ... is this course publicly available? be fun to take a look at it.
The course materials were just the labs, along with succinct syntax notes. Exercises were just "partition that drive according to the following criteria", "create a PV/VG/LV that size", "build a level 1 RAID volume", "declare that RAID component invalid", that sort of things. Theory was kept at a minimum and was orally exposed.
When managing educational efforts, I have encouraged instructors to concentrate in hands-on training, write minimal labs guides, and take the "Internet is already filled with info" approach wrt other docs. Of course, guidance was given about where and what to read: look for docs from your distro, learn to know when docs are out of date, etc.
My experience is that non-academia students, while enthusiastic, lack studying muscle, and handouts you throw at them are seldom read or understood. Face-to-face is different; that's the place where your theory should go.
However, they can build up a practical understanding of the task they must accomplish, so they can attempt to read documentation later. The labs should pull the theory, while University does the other way around. I found out this while being an instructor for Cisco CCNA program -- it wasn't an easy switch.
On Sat, 18 Sep 2010, Robert P. J. Day wrote:
To: CentOS mailing list centos@centos.org From: Robert P. J. Day rpjday@crashcourse.ca Subject: Re: [CentOS] looking for cool, post-install things to do on a centos 5.5 system
i'm not ignoring all of the suggestions so far (i'm taking note of all of them) but as rp herrold suggests, a lot of this is getting pretty far afield, so let me drag this back on-topic.
i'm looking for cool things that can be added into a very generic 5-day course in basic RHEL (centos) administration that wouldn't normally be covered. i've provided the outline on which the 3rd party courseware is based -- it was written to mimic red hat's RH 131 course:
https://www.redhat.com/courses/rh131_red_hat_linux_system_administration/
so you can see what's already there, and i'm after cool tips, tricks and utilities that people who are long-time RHEL/centos admins have learned that they think are terrifically useful that i can sneak in as bonus content.
the caveat is that i don't want to add topics that would take longer than, say, a half day since i can always take a topic like that, extend it to a full-day course, and market it *separately*.
case in point: virtualization. the course already covers virtualization *very* briefly and i don't want to make that section any longer since i can easily see having a full-day course on that topic.
*possibly* the same thing with puppet or cfengine (both excellent suggestions). i'm thinking of at least demoing one or both and, depending on the interest, perhaps suggesting a full day course in enterprise-wide administration.
anyway, i appreciate all of the ideas so far, and i'm definitely going to use some of them. thanks muchly.
rday
p.s. one stupendously trivial idea i had was to give each student a cheap USB drive and use that as the vehicle for playing with filesystem utilities. with an $8 2G drive, i can demonstrate concepts like hotplugging, udev, LVM and so on, knowing i'll never risk the contents of the hard drive.
What about showing them how to use the GParted Live CD. They can practice partitioning the USB drive, which comes up as /dev/sd???
As far as Linux is concerned, a USB drive is just another block device like /dev/sda
HTH
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
On 17/09/2010 13:41, Les Mikesell wrote:
Oh - and how to install and use freenx/NX for remote access.
And how about Serial Over LAN using IPMI if your kit supports it? Very useful is you've broken things... (speaking from experience :-)
D
On 17/09/10 08:39, Robert P. J. Day wrote:
(note: i asked this a few days ago but it *appears* that that post was tossed due to getting excessive bounces from my account. so i'm posting it again, apologies if you're seeing it a second time.)
over the next several weeks, i'm teaching some courses in RHEL admin but (unsurprisingly) i'll be using centos 5.5. it's a decently-written, 3rd party course, all the generic, standard admin topics but it does leave me about a 1/2 day to throw in any cool stuff i want to add.
so, any recommendations for neat things that people here have done in the way of what can be added to or configured on a centos server system? the course covers all the standard topics -- installation, package management, service management, filesystem maintenance, that sort of thing. so i'm looking for bonus, neat stuff that others here do as a matter of course when putting together a centos system.
logging utilities? intrusion detection? monitoring? anything that leaps to mind that i can use to fill up a few more hours. i'm already thinking of showing how to build and boot a new kernel. other ideas? thanks.
How about how to subscribe to the CentOS mailing list? ;-)
A.
On Fri, Sep 17, 2010 at 4:39 AM, Robert P. J. Day rpjday@crashcourse.ca wrote:
logging utilities? intrusion detection? monitoring? anything that leaps to mind that i can use to fill up a few more hours. i'm already thinking of showing how to build and boot a new kernel. other ideas? thanks.
If your students are new to RHEL/CentOS admin, they will appreciate some education regarding what and how to search into docs and other information sources: the Guides, CentOS community resources such as Forum, Wiki or this mailing list.
Proper scripting abilities are perhaps beyond reach for a short course, but you could at least show off some one-liners or those short, stunningly useful examples to help them get the idea that they definitely should get their feet wet on it sooner or later.
Eduardo Grosclaude wrote:
On Fri, Sep 17, 2010 at 4:39 AM, Robert P. J. Day rpjday@crashcourse.ca wrote:
logging utilities? intrusion detection? monitoring? anything that leaps to mind that i can use to fill up a few more hours. i'm already thinking of showing how to build and boot a new kernel. other ideas? thanks.
If your students are new to RHEL/CentOS admin, they will appreciate some education regarding what and how to search into docs and other information sources: the Guides, CentOS community resources such as Forum, Wiki or this mailing list.
I always push the second chapter of Frisch's Essential Systems Administration (O'Reilly, of course) at folks. That's the chapter entitled "The Unix Way", which gives a *really* good overview of the archetecture of *Nix, what's where and why.
Proper scripting abilities are perhaps beyond reach for a short course, but you could at least show off some one-liners or those short, stunningly useful examples to help them get the idea that they definitely should get their feet wet on it sooner or later.
awk, awk! Perl's a day, minimum, by itself, but awk you can do in an hour or two, and have immediate results.
mark
On 9/17/2010 8:24 AM, m.roth@5-cent.us wrote:
Proper scripting abilities are perhaps beyond reach for a short course, but you could at least show off some one-liners or those short, stunningly useful examples to help them get the idea that they definitely should get their feet wet on it sooner or later.
awk, awk! Perl's a day, minimum, by itself, but awk you can do in an hour or two, and have immediate results.
But awk is a dead end that can't do a lot of things by itself. And learning how to embed awk into other scripts is even more syntactically obscure than just using perl in the first place. Besides, perl's '-c' check and debug facilities make it much more usable to beginners than awk's propensity to find errors mid-run (and worse, mid-some-other-script because you had to embed it).
On Fri, 17 Sep 2010, Les Mikesell wrote:
On 9/17/2010 8:24 AM, m.roth@5-cent.us wrote:
Proper scripting abilities are perhaps beyond reach for a short course, but you could at least show off some one-liners or those short, stunningly useful examples to help them get the idea that they definitely should get their feet wet on it sooner or later.
awk, awk! Perl's a day, minimum, by itself, but awk you can do in an hour or two, and have immediate results.
But awk is a dead end that can't do a lot of things by itself. And learning how to embed awk into other scripts is even more syntactically obscure than just using perl in the first place. Besides, perl's '-c' check and debug facilities make it much more usable to beginners than awk's propensity to find errors mid-run (and worse, mid-some-other-script because you had to embed it).
i will probably throw in an hour or so of shell scripting, just enough to whet their appetites and make them want an actual course. :-)
rday
On 9/17/2010 10:02 AM, Robert P. J. Day wrote:
Proper scripting abilities are perhaps beyond reach for a short course, but you could at least show off some one-liners or those short, stunningly useful examples to help them get the idea that they definitely should get their feet wet on it sooner or later.
awk, awk! Perl's a day, minimum, by itself, but awk you can do in an hour or two, and have immediate results.
But awk is a dead end that can't do a lot of things by itself. And learning how to embed awk into other scripts is even more syntactically obscure than just using perl in the first place. Besides, perl's '-c' check and debug facilities make it much more usable to beginners than awk's propensity to find errors mid-run (and worse, mid-some-other-script because you had to embed it).
i will probably throw in an hour or so of shell scripting, just enough to whet their appetites and make them want an actual course. :-)
Yes, at least get across the concept that anything they do on the command line can be saved in a file and run again - and any command that needs to be repeated with small differences can be easily wrapped in a 'for' loop with a list of substitutions. And if the course doesn't already cover it, point out the ability to ^r recall previous commands and repeat with simple edits.
On Fri, 17 Sep 2010, Robert P. J. Day wrote:
To: CentOS mailing list centos@centos.org From: Robert P. J. Day rpjday@crashcourse.ca Subject: Re: [CentOS] looking for cool, post-install things to do on a centos 5.5 system
On Fri, 17 Sep 2010, Les Mikesell wrote:
On 9/17/2010 8:24 AM, m.roth@5-cent.us wrote:
Proper scripting abilities are perhaps beyond reach for a short course, but you could at least show off some one-liners or those short, stunningly useful examples to help them get the idea that they definitely should get their feet wet on it sooner or later.
awk, awk! Perl's a day, minimum, by itself, but awk you can do in an hour or two, and have immediate results.
But awk is a dead end that can't do a lot of things by itself. And learning how to embed awk into other scripts is even more syntactically obscure than just using perl in the first place. Besides, perl's '-c' check and debug facilities make it much more usable to beginners than awk's propensity to find errors mid-run (and worse, mid-some-other-script because you had to embed it).
i will probably throw in an hour or so of shell scripting, just enough to whet their appetites and make them want an actual course. :-)
rday
What about something on using the find command and xargs?
Most shell commands can be piggy-backed on the find command.
And also as mentioned, how and where to find documentation?
pinfo is a nice man page and info page viewer, with Lynx like navigation. Much easier than trying to how to use the info command.
# pinfo find
1 Introduction **************
This manual shows how to find files that meet criteria you specify, and how to perform various actions on the files that you find. The principal programs that you use to perform these tasks are `find', `locate', and `xargs'. Some of the examples in this manual use capabilities specific to the GNU versions of those programs.
HTH
Keith Roberts
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
Les Mikesell wrote:
On 9/17/2010 8:24 AM, m.roth@5-cent.us wrote:
Proper scripting abilities are perhaps beyond reach for a short course, but you could at least show off some one-liners or those short, stunningly useful examples to help them get the idea that they definitely should get their feet wet on it sooner or later.
awk, awk! Perl's a day, minimum, by itself, but awk you can do in an hour or two, and have immediate results.
But awk is a dead end that can't do a lot of things by itself. And
So, what's the longest awk scripts you've ever written, Mike? It works wonderfully well for what it was intended - and mostly, I use it for reports or data conversion.
learning how to embed awk into other scripts is even more syntactically obscure than just using perl in the first place. Besides, perl's '-c' check and debug facilities make it much more usable to beginners than awk's propensity to find errors mid-run (and worse, mid-some-other-script because you had to embed it).
Misuse of awk.
mark "why, yes, I *have* written 100 and 200 line awk scripts to do data converstion and data validation"
On 9/17/2010 10:12 AM, m.roth@5-cent.us wrote:
Les Mikesell wrote:
On 9/17/2010 8:24 AM, m.roth@5-cent.us wrote:
Proper scripting abilities are perhaps beyond reach for a short course, but you could at least show off some one-liners or those short, stunningly useful examples to help them get the idea that they definitely should get their feet wet on it sooner or later.
awk, awk! Perl's a day, minimum, by itself, but awk you can do in an hour or two, and have immediate results.
But awk is a dead end that can't do a lot of things by itself. And
So, what's the longest awk scripts you've ever written, Mike? It works wonderfully well for what it was intended - and mostly, I use it for reports or data conversion.
Don't think I've ever written one from scratch, at least not since perl was around because it was too painful to debug. I agree that it works fine when you copy someone else's already-debugged code. I'm not recommending never using awk, I just don't see the point of learning to write it.
learning how to embed awk into other scripts is even more syntactically obscure than just using perl in the first place. Besides, perl's '-c' check and debug facilities make it much more usable to beginners than awk's propensity to find errors mid-run (and worse, mid-some-other-script because you had to embed it).
Misuse of awk.
mark "why, yes, I *have* written 100 and 200 line awk scripts to do data converstion and data validation"
But why, when very likely better versions of whatever you were doing have already been written and debugged as CPAN perl modules? Would you do something like time parsing or format conversions in awk, or extract mime attachment from a mail message? Those sound simple but aren't and in perl you only have to write a couple of lines yourself to do them.
Les Mikesell wrote:
On 9/17/2010 10:12 AM, m.roth@5-cent.us wrote:
Les Mikesell wrote:
On 9/17/2010 8:24 AM, m.roth@5-cent.us wrote:
Proper scripting abilities are perhaps beyond reach for a short course, but you could at least show off some one-liners or those short, stunningly useful examples to help them get the idea that they definitely should get their feet wet on it sooner or later.
awk, awk! Perl's a day, minimum, by itself, but awk you can do in an hour or two, and have immediate results.
But awk is a dead end that can't do a lot of things by itself. And
So, what's the longest awk scripts you've ever written, Mike? It works wonderfully well for what it was intended - and mostly, I use it for reports or data conversion.
Don't think I've ever written one from scratch, at least not since perl was around because it was too painful to debug. I agree that it works fine when you copy someone else's already-debugged code. I'm not recommending never using awk, I just don't see the point of learning to write it.
learning how to embed awk into other scripts is even more syntactically obscure than just using perl in the first place. Besides, perl's '-c' check and debug facilities make it much more usable to beginners than awk's propensity to find errors mid-run (and worse, mid-some-other-script because you had to embed it).
Misuse of awk.
mark "why, yes, I *have* written 100 and 200 line awk scripts to do data converstion and data validation"But why, when very likely better versions of whatever you were doing have already been written and debugged as CPAN perl modules? Would you do something like time parsing or format conversions in awk, or extract mime attachment from a mail message? Those sound simple but aren't and in perl you only have to write a couple of lines yourself to do them.
Ah, no. I wrote 30 scripts around '91-'92 to take datafiles from 30 sources and reformat them, to feed to the C program I'd written with embedded sql, in place of the d/b's sqlloader (*bleah*). Then, 11 years ago, I wrote a validation program for data that was being loaded by another program that I didn't want to change; the data had been exported from ArcInfo, and had to go into our Oracle d/b.
Really simple to do in awk - just so much of it, and no, perl would have offered no improved/shorter way to do it, and yes, I do know perl - in '04, for example, I rewrote a call routing and billing system from perl (written by my then-manager, who'd never studied programming, can you say spaghetti?) into reasonable perl. Actually, I just wrote a scraper in perl, using HTML::Parser. Anyway, the point of that was to demonstrate that I know both, and awk is better, IMO, for some jobs.
mark
On Fri, Sep 17, 2010 at 11:47, m.roth@5-cent.us wrote:
Ah, no. I wrote 30 scripts around '91-'92 to take datafiles from 30 sources and reformat them, to feed to the C program I'd written with embedded sql, in place of the d/b's sqlloader (*bleah*). Then, 11 years ago, I wrote a validation program for data that was being loaded by another program that I didn't want to change; the data had been exported from ArcInfo, and had to go into our Oracle d/b.
Really simple to do in awk - just so much of it, and no, perl would have offered no improved/shorter way to do it, and yes, I do know perl - in '04, for example, I rewrote a call routing and billing system from perl (written by my then-manager, who'd never studied programming, can you say spaghetti?) into reasonable perl. Actually, I just wrote a scraper in perl, using HTML::Parser. Anyway, the point of that was to demonstrate that I know both, and awk is better, IMO, for some jobs.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
It's all about picking the right tool for the job. Python is good for some things, perl for others, awk for still different things... It is the beauty of Linux... John
On 9/17/2010 10:52 AM, John Kennedy wrote:
It's all about picking the right tool for the job. Python is good for some things, perl for others, awk for still different things... It is the beauty of Linux...
But there are things a beginner won't know when making this choice - like the limitations of what a language can do, availability of library support, cross-platform support, probability of future language changes that aren't backwards compatible, etc., etc., all of which turn out to be important in the long run as soon as you get past throw-away one liners.
On 9/17/2010 10:47 AM, m.roth@5-cent.us wrote:
Ah, no. I wrote 30 scripts around '91-'92 to take datafiles from 30 sources and reformat them, to feed to the C program I'd written with embedded sql, in place of the d/b's sqlloader (*bleah*). Then, 11 years ago, I wrote a validation program for data that was being loaded by another program that I didn't want to change; the data had been exported from ArcInfo, and had to go into our Oracle d/b.
Really simple to do in awk - just so much of it, and no, perl would have offered no improved/shorter way to do it,
I don't get it. Why wouldn't you just talk to the db directly with perl's dbi/dbd, replacing both the awk and C parts? I do that all the time. Or was that before dbi - or the dbd you needed?
and yes, I do know perl - in
'04, for example, I rewrote a call routing and billing system from perl (written by my then-manager, who'd never studied programming, can you say spaghetti?) into reasonable perl. Actually, I just wrote a scraper in perl, using HTML::Parser. Anyway, the point of that was to demonstrate that I know both, and awk is better, IMO, for some jobs.
That depends on how you define better. I can see how it could save a microsecond of loading time on tiny jobs, but not how it can do anything functionally better. Have you tried feeding one of your long scripts to a2p and timing some job with enough input to matter? I'd expect perl to win anything where there is enough actual work to make up for the compile/tokenize pass.
Les Mikesell wrote:
On 9/17/2010 10:47 AM, m.roth@5-cent.us wrote:
Ah, no. I wrote 30 scripts around '91-'92 to take datafiles from 30 sources and reformat them, to feed to the C program I'd written with embedded sql, in place of the d/b's sqlloader (*bleah*). Then, 11 years ago, I wrote a validation program for data that was being loaded by another program that I didn't want to change; the data had been exported from ArcInfo, and had to go into our Oracle d/b.
Really simple to do in awk - just so much of it, and no, perl would have offered no improved/shorter way to do it,
I don't get it. Why wouldn't you just talk to the db directly with perl's dbi/dbd, replacing both the awk and C parts? I do that all the time. Or was that before dbi - or the dbd you needed?
Mike, you really aren't reading all of what I wrote. Perl itself wasn't available in '91-'92. I'd already written the C program, and then the hypothesis that our company would be able to tell all the sources of the data what format to put it in was shown to be less realistic than the typical tv commercial.
I don't know the state of dbd/dbi in '98 or '99, but I was *not* going to touch the existing program that loaded the data, and I was trying to get just very basic validation, which included feedback as to what was wrong with each bad record (and let the rest be loaded).
and yes, I do know perl - in
'04, for example, I rewrote a call routing and billing system from perl (written by my then-manager, who'd never studied programming, can you say spaghetti?) into reasonable perl. Actually, I just wrote a scraper in perl, using HTML::Parser. Anyway, the point of that was to demonstrate that I know both, and awk is better, IMO, for some jobs.
That depends on how you define better. I can see how it could save a microsecond of loading time on tiny jobs, but not how it can do anything functionally better. Have you tried feeding one of your long scripts to a2p and timing some job with enough input to matter? I'd expect perl to win anything where there is enough actual work to make up for the compile/tokenize pass.
Nope. And the one company no longer exists as such, it having been sold over 10 years ago, and that project over for something like 15 years; the other, I've no idea what they're doing these days with the City of Chicago's 911 system for geodata loading, but I'd be surprised if they weren't still using my system, money being tight, and the VAR I worked with being cheaper than ever.
mark
On 9/17/2010 12:45 PM, m.roth@5-cent.us wrote:
I don't get it. Why wouldn't you just talk to the db directly with perl's dbi/dbd, replacing both the awk and C parts? I do that all the time. Or was that before dbi - or the dbd you needed?
Mike, you really aren't reading all of what I wrote. Perl itself wasn't available in '91-'92.
I think you are mistaken about that. "Programming Perl", covering version 4 of perl was published in 1991. Check the printing history if you have a newer copy. Perl itself goes back to 1987 or so. I'm pretty sure I wrote things in version 1 downloaded through usenet. Not sure when dbi/dbd came around but before that there were things like oraperl with specific database clients grafted in.
I'll grant the historical value of awk for the prior decade and for the conceptual introduction of hash arrays for scripting languages, though.
On Fri, Sep 17, 2010 at 3:09 PM, Les Mikesell lesmikesell@gmail.com wrote:
On 9/17/2010 12:45 PM, m.roth@5-cent.us wrote:
I don't get it. Why wouldn't you just talk to the db directly with perl's dbi/dbd, replacing both the awk and C parts? I do that all the time. Or was that before dbi - or the dbd you needed?
Mike, you really aren't reading all of what I wrote. Perl itself wasn't available in '91-'92.
I think you are mistaken about that. "Programming Perl", covering version 4 of perl was published in 1991. Check the printing history if you have a newer copy. Perl itself goes back to 1987 or so. I'm pretty sure I wrote things in version 1 downloaded through usenet. Not sure when dbi/dbd came around but before that there were things like oraperl with specific database clients grafted in.
I used Perl4 under DOS to write connective tissue for my business systems in C back in '92. But then, awk under DOS did a lot of help too.
Les Mikesell wrote:
On 9/17/2010 12:45 PM, m.roth@5-cent.us wrote:
I don't get it. Why wouldn't you just talk to the db directly with perl's dbi/dbd, replacing both the awk and C parts? I do that all the time. Or was that before dbi - or the dbd you needed?
Mike, you really aren't reading all of what I wrote. Perl itself wasn't available in '91-'92.
I think you are mistaken about that. "Programming Perl", covering version 4 of perl was published in 1991. Check the printing history if you have a newer copy. Perl itself goes back to 1987 or so. I'm pretty sure I wrote things in version 1 downloaded through usenet. Not sure when dbi/dbd came around but before that there were things like oraperl with specific database clients grafted in.
That may be, but it was *not* part of the standard installations, AFAIK. I remember someone handed me some documentation around '92 or '93, and it wasn't very clear. Meanwhile, awk was there and available and reliable.
I'll grant the historical value of awk for the prior decade and for the conceptual introduction of hash arrays for scripting languages, though.
YES! I *adore* associative arrays.
You, on the other hand, remind me of Larry Wall, who popped into comp.lang.awk around '93 or '94, and rather than try to help someone solve his awk problem, tried to get him to rewrite it into perl....
mark "inappropriate venue, to say the least"
On 09/17/10 12:12 PM, m.roth@5-cent.us wrote:
You, on the other hand, remind me of Larry Wall, who popped into comp.lang.awk around '93 or '94, and rather than try to help someone solve his awk problem, tried to get him to rewrite it into perl....
well, not all problems are nails, even if your only tool is a hammer.
On 9/17/2010 2:12 PM, m.roth@5-cent.us wrote:
You, on the other hand, remind me of Larry Wall, who popped into comp.lang.awk around '93 or '94, and rather than try to help someone solve his awk problem, tried to get him to rewrite it into perl....
I'll take that as a compliment. Larry has always been brilliant. Note that I'm not against continuing to use anything that works - I just don't see the point in learning awk today since there are better and more completed alternatives today and think it is a bad idea to recommend to anyone.
On Fri, 17 Sep 2010, m.roth@5-cent.us wrote:
So, what's the longest awk scripts you've ever written, Mike? It works wonderfully well for what it was intended - and mostly, I use it for reports or data conversion.
Upwards of 1000 lines..back in the 90's.
---------------------------------------------------------------------- Jim Wildman, CISSP, RHCE jim@rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine
I know the OP asked for "cool" things to do, but I'll add my vote to those who suggested highlighting configuration management. I'm not sure how much puppet or cfengine you teach in a half-day, but I'm fairly confident you could cover:
1. considering configuration files to be code -- it needs to be in a repository
2. setting up a Subversion or git repository and some possible ways of laying out a configuration repository (per host, per service, etc)
3. committing changes, recovering older configs when newer ones introduce regressions
Personally, I like Subversion for configuration repositories because (imo) sysadmins usually like having an authoritative repo rather than a widely branched one -- but git is on the rise and is certainly worth considering.
Other, slightly related, suggestions include setting up a documentation wiki and/or a ticketing system. Trac can do both, but there are plenty of worthwhile alternatives.
On 9/17/2010 10:14 AM, Paul Heinlein wrote:
I know the OP asked for "cool" things to do, but I'll add my vote to those who suggested highlighting configuration management. I'm not sure how much puppet or cfengine you teach in a half-day, but I'm fairly confident you could cover:
considering configuration files to be code -- it needs to be in a repository
setting up a Subversion or git repository and some possible ways of laying out a configuration repository (per host, per service, etc)
committing changes, recovering older configs when newer ones introduce regressions
Personally, I like Subversion for configuration repositories because (imo) sysadmins usually like having an authoritative repo rather than a widely branched one -- but git is on the rise and is certainly worth considering.
Has anyone ever standardized a way to do this that will work across more than a few platforms? I've always thought there should be a way to at least make a subversion repository holding copies of all of /etc of all of your machines where similar hosts are branches from a master and current changes are always checked back in. Then even if you don't use it to control and push changes you could at least easily view the changes over time on any host and the difference between any two hosts.
On Fri, 17 Sep 2010, Les Mikesell wrote:
Has anyone ever standardized a way to do this that will work across more than a few platforms? I've always thought there should be a way to at least make a subversion repository holding copies of all of /etc of all of your machines where similar hosts are branches from a master and current changes are always checked back in. Then even if you don't use it to control and push changes you could at least easily view the changes over time on any host and the difference between any two hosts.
Russ just pointed me at this
etckeeper..
http://joey.kitenet.net/code/etckeeper/
among other things it includes a plugin for yum so 'yum install' includes a commit.. Very nice touch..
---------------------------------------------------------------------- Jim Wildman, CISSP, RHCE jim@rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine
On Fri, Sep 17, 2010 at 11:14 AM, Paul Heinlein heinlein@madboa.com wrote:
I know the OP asked for "cool" things to do, but I'll add my vote to those who suggested highlighting configuration management. I'm not sure how much puppet or cfengine you teach in a half-day, but I'm fairly confident you could cover:
Yes! If there's anything I wish were taught to new system administrators, it's that your configuration is your code.
1. considering configuration files to be code -- it needs to be in a repository
2. setting up a Subversion or git repository and some possible ways of laying out a configuration repository (per host, per service, etc)
3. committing changes, recovering older configs when newer ones introduce regressions
My general method is to keep a CVS committed directory somewhere on the root filesystem with all configurations. Then I symlink the tracked files back to that repository. For example:
/etc/hosts --> /configs/HOSTNAME/etc/hosts /etc/syslog.conf --> /configs/HOSTNAME/etc/syslog.conf
Restoring a machine's "identity" is just a simple matter of checking out that host's configuration directory then running a script to create the symlink.s
Personally, I like Subversion for configuration repositories because (imo) sysadmins usually like having an authoritative repo rather than a widely branched one -- but git is on the rise and is certainly worth considering.
Other, slightly related, suggestions include setting up a documentation wiki and/or a ticketing system. Trac can do both, but there are plenty of worthwhile alternatives.
-- Paul Heinlein <> heinlein@madboa.com <> http://www.madboa.com/ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Fri, 17 Sep 2010, Kwan Lowe wrote:
My general method is to keep a CVS committed directory somewhere on the root filesystem with all configurations. Then I symlink the tracked files back to that repository. For example:
/etc/hosts --> /configs/HOSTNAME/etc/hosts /etc/syslog.conf --> /configs/HOSTNAME/etc/syslog.conf
Restoring a machine's "identity" is just a simple matter of checking out that host's configuration directory then running a script to create the symlink.s
I've keyed configuration repositories to HOSTNAME before (and still do for very small installations), but over the long haul I've found the service-keyed repository more to my liking. In particular, cfengine makes it easy to work that way:
/etc/motd -> /r/systems/motd/motd.HOSTNAME /etc/openldap/slapd.conf -> /r/services/openldap/slapd.conf.HOSTNAME
One benefit of this method is that you can have a single file that works for a whole class of machines, e.g.,
/etc/syslog.conf -> /r/services/syslog/syslog.conf.client-linux
where "client" becomes "server" for syslog servers and "linux" becomes "macosx" or "sunos" depending on the platform.
As I said, however, a lot of that arrangement is a function of the way that cfengine works. I'd probably do it differently if I were using a different tool.
On Fri, Sep 17, 2010 at 3:52 PM, Paul Heinlein heinlein@madboa.com wrote: [snip]
I've keyed configuration repositories to HOSTNAME before (and still do for very small installations), but over the long haul I've found the service-keyed repository more to my liking. In particular, cfengine makes it easy to work that way:
/etc/motd -> /r/systems/motd/motd.HOSTNAME /etc/openldap/slapd.conf -> /r/services/openldap/slapd.conf.HOSTNAME
One benefit of this method is that you can have a single file that works for a whole class of machines, e.g.,
/etc/syslog.conf -> /r/services/syslog/syslog.conf.client-linux
where "client" becomes "server" for syslog servers and "linux" becomes "macosx" or "sunos" depending on the platform.
As I said, however, a lot of that arrangement is a function of the way that cfengine works. I'd probably do it differently if I were using a different tool.
There is a benefit of a service centered view and may adopt it at some point. I have used cfengine, and more recently, puppet and they do lend themselves to that approach. I am still looking to be able to provision a system with minimal interaction *and* layer on an identity. However it's done though, I completely agree with your original point that it needs be managed whether on 5 systems or 500.
On 09/17/2010 03:39 AM, Robert P. J. Day wrote:
(note: i asked this a few days ago but it *appears* that that post was tossed due to getting excessive bounces from my account. so i'm posting it again, apologies if you're seeing it a second time.)
over the next several weeks, i'm teaching some courses in RHEL admin but (unsurprisingly) i'll be using centos 5.5. it's a decently-written, 3rd party course, all the generic, standard admin topics but it does leave me about a 1/2 day to throw in any cool stuff i want to add.
so, any recommendations for neat things that people here have done in the way of what can be added to or configured on a centos server system? the course covers all the standard topics -- installation, package management, service management, filesystem maintenance, that sort of thing. so i'm looking for bonus, neat stuff that others here do as a matter of course when putting together a centos system.
logging utilities? intrusion detection? monitoring? anything that leaps to mind that i can use to fill up a few more hours. i'm already thinking of showing how to build and boot a new kernel. other ideas? thanks.
rday
I've done quite a few things. Recently, I just run puppet and let it do EVERYTHING for whatever a system might need. But things I have done in the past are autodetect if the system is a vm and install vmware-tools, find the next ip address available in DNS for the particular subnet the newly installed system is in and dynamically update forward and reverse (including a helpful TXT record which fit a known convention), run yum update and reboot, and even create a qtree on netapp automatically. Just a quick few things.. I also do some stuff during pre installation like align the disk on proper boundaries and enable software raid according to the meta data associated with the system record in cobbler. Cobbler is nice as a subscription means to dynamically alter kickstart configs so I can add 'raid=5' as meta data for instance the the vm will build itself with raid5 (if it can of course). Same things applies to selinux, firewall, and other features that need to be enabled very early on and puppet just checks to make sure it's still true.
I've moved away from doing stuff in post install and instead let puppet handle pretty much everything. API's are great for this.
On Fri, Sep 17, 2010 at 2:39 AM, Robert P. J. Day rpjday@crashcourse.ca wrote:
logging utilities? intrusion detection? monitoring? anything that leaps to mind that i can use to fill up a few more hours. i'm already thinking of showing how to build and boot a new kernel. other ideas? thanks.
Cacti, pmacct, pnrg ...
kind regards/ldv
On Sep 17, 2010, at 3:39 AM, "Robert P. J. Day" rpjday@crashcourse.ca wrote:
(note: i asked this a few days ago but it *appears* that that post was tossed due to getting excessive bounces from my account. so i'm posting it again, apologies if you're seeing it a second time.)
over the next several weeks, i'm teaching some courses in RHEL admin but (unsurprisingly) i'll be using centos 5.5. it's a decently-written, 3rd party course, all the generic, standard admin topics but it does leave me about a 1/2 day to throw in any cool stuff i want to add.
so, any recommendations for neat things that people here have done in the way of what can be added to or configured on a centos server system? the course covers all the standard topics -- installation, package management, service management, filesystem maintenance, that sort of thing. so i'm looking for bonus, neat stuff that others here do as a matter of course when putting together a centos system.
logging utilities? intrusion detection? monitoring? anything that leaps to mind that i can use to fill up a few more hours. i'm already thinking of showing how to build and boot a new kernel. other ideas? thanks.
I haven't read the 80+ posts in entirety, so these might have been mentioned, but three ideas that could work:
1) RHEL for the security admin, where it goes in depth on hardening RHEL, intrusion detection and intrusion prevention.
2) RHEL for storage admins, software/hardware RAID, volume management and snapshots, NFS/CIFS network file systems, FCoE/iSCSI shared block devices.
3) RHEL for the network admin, firewalls, routers, bridges, traffic shaping, route load balancing, and network traffic monitoring.
I think these can be expanded out some more, and while there might be some overlap they should be each more targeted then a broad course.
-Ross
-
Alan Hodgson -
andrew.hearn＠aaisp.net.uk -
Brunner, Brian T. -
Daniel Bird -
Eduardo Grosclaude -
Frank Cox -
Jim Wildman -
John Doe -
John Kennedy -
John R Pierce -
JohnS -
Keith Roberts -
Kwan Lowe -
Larry Vaden -
Les Mikesell -
m.roth＠5-cent.us -
Michel van Deventer -
Natxo Asenjo -
Paul Heinlein -
R P Herrold -
Robert P. J. Day -
Ross Walker -
Scott McClanahan -
Scott Robbins