On Sat, 2 Oct 2010, Yves Dorfsman wrote: >> >> On Oct 2, 2010, at 4:01 PM, Rob Cherry wrote: >> >>> I fear that my days of Solaris bigotry are very outdated. I can ignore the >>> Linux world no longer. I can also no longer assume that knowing Solaris is >>> enough to fake it for enterprise Linux environments. As such I wanted to >>> ask all the linux admins out there 2 questions - >>> >>> - What admin task did you do in the last week that you consider a linux >>> specific thing? i.e. editing the password file doesnt count, dealing with >>> ReiserFS does.... >> >> Packaged software installation usually uses different tools, so get >> used to RPM, YUM, etc., depending on the distro. > > Absolutely! > > The two largest families out there are rpm (RedHat, Suse) based and deb > (Debian, Ubuntu) based. > > For RPMs, you need to learn about the commands "rpm", and "yum" (only present > on newer versions). > > For DEBs, learn about "dpkg", "apt-get", "apt-cache", and optionally look at > "synaptic" and its friends. > > > Look into: > "sync", it behaves differently, > > /etc/modules > /etc/modprobe.d
lsmod (list modules) lspci (info on pci) a _lot_ of info in /proc. well worth learning > /etc/sysctl.conf > the "sysctl" command > /etc/security/limits.conf > > the "dmidecode" command > > the "lsb_release" command > > CUPS > > The kernel parameters: > http://www.kernel.org/doc/Documentation/kernel-parameters.txt > those are parameters you pass to the kernel from your boot loaders, for > example to be able to boot in single user mode, disable acpi or force the > console to a specific mode. I have a few quick notes on how to use them in > gurb and lilo at: > http://www.sollers.ca/blog/2007/GA-M57SLI-S4_hangs_on_boot/ > But look more into details for whichever boot loader / distro you use, make > sure you can bring up a box in single user mode at 3h00 am :-) > > NFS, both the client and the server needs to be tuned (I wish I could tell you > more about this, but I am still playing with this - check a recent thread on > the subject on the tech mailing list). > >>> - Linux War stories, What was the worst linux disaster you have had that I >>> should read up on to make sure I could fix it if hit with it in future. >>> Dont have to go into much detail as these can get long, but a general >>> pointer to give me some reading homework would be ideal. >> >> IME, filesystem corruption. ext* can corrupt itself in ways I've >> never seen on other UNIX systems. It doesn't help that Linux is >> often running on commodity-level hardware. It's not a bad idea to >> familiarize yourself with ext2/3 and other filesystems, as well as >> Linux RAID and LVM software. > > Yes, and not just the filesystem, the LVM gets corrupted too. If you have a > choice of filesystem, read and experiment. Understand how the journal works on > ext3 and ext4 (the default might surprise you). Do seriously consider > alternative filesystems (XFS, JFS). > > Personally the biggest problem I run into with Linux distros is being caught > between a brand new piece of hardware the needs the latest version of the > distro to install easily (you typically can always install, but it often takes > more work than it should), and the software vendor which will most of the time > only support older versions of the distro. for the most part I deal with this by running my own kernels, but that's something some companies frown on. > I personally hate gurb, but that's probably an issue with me more than with > grub. possibly, but i feel the same way. it makes the common case easy, but I've run into too many situations where it was really hard to make work because it was not a common case (for example, a system with a dozen drives where i want to boot off of something that shows up late in the sequence) lilo isn't as trivial in the common case, but it's far simpler (both to diagnose, and in it's code) and i haven't run into a situation where I couldn't use it. David Lang _______________________________________________ Discuss mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
