[svlug] Location of bash on different Linuxes

[Tin Le]

-----BEGIN PGP SIGNED MESSAGE-----


> > SysAdmin position or title per se.  In the mainframe/mini world, there
> > were "Operators", who changes tapes, oversee day to day administrative
> > stuffs, but the real OS jocks were usually system programmers.

> You forgot the most important ones (?), hardware support guys who made
> machines run on the first place. A hardware engineers were treated with a
> shot of whiskey or schnaps just for showing up, and lunch or dinner after
> the system was brought back online. These days they don't want to have
> you around.

Heh, I remember those days.  Rows upon rows of diskpacks and 1/2" reel
to reel tape drives.  Still have boxes of them because I backed up my
stuffs before leaving a job.

Oh well, hardware tend to be more reliable and replaceable.  Some jobs
are meant to be go away, harsh as that may sound.

Side Note: I am actually a hardware person, EE, who later got a CS degree.
My first job out of college was for GTE working on phone switches,
PBX, SS5, LDMs, DSU/CSU, cables, etc.  So I took the roundabout way to
get to where I am.  Never had training as "sysadmin" nor actually had
such a title.  It was always engineer this or that title...  As I see
technology changes, I changed and adapted along the way.

I would not call myself one either, although I may play one at work ;-)

> Now for the most important question: do you know what was the most
> noticeable difference between the hardware and software guys in good old
> days? Worth a bottle of beer :-)

Just one? ;-)  From the dim recesses of my memory, I remember that hw
guys carrying larger briefcase for parts.  Yours may be different, mine
are mostly with the IBM and Unisys bunch as that was my early experiences.

> > In the UNIX world, the OS designers usually also admin their own system.

> Just like I said, some do some don't, so you agree with my statement
> above. Worked on Solaris developer's workstations at Sun a few times and
> they would not bother with NIS for example ...

Ok, you are right.  Heh, I've worked for Sun and for various other
companies that write software for Sun workstation.  I hated NIS/YP.
I thought it was a bad implementation of a nice idea.  NIS is better than
YP, but still not all there as it is simply patching around YP's problems.
It would have been better to throw out all of YP and redo from scratch.
Oops, getting off topic ;-)

> > They've already experienced all the problems that a "sysadmin" would have.

> All? I wish! They would put us out of business if that was even close.

But the team that merged SunOS and SysV has.  They are actually some of
the most knowlegeable sysadmins around besides being kernel jocks.

> That's fine, and when they put fsck into /sbin then we can talk about
> consistency or something that makes sense.  It seems to me it was very
> foggy when they decided to put /usr/sbin/fsck where it is. When I need it
> most is not accessible. How about /usr/sbin/mount?

I actually can guess at their reasoning for putting fsck in
/usr/sbin instead of /sbin.  As for mount, it's actually in
/etc/fs/filesystemname/mount check it out if you can get on a Solaris box.
e.g. for UFS, it's in /etc/fs/ufs/mount and that is static binary.

It has been years since I do serious admin of S5R4 boxes (and Solaris),
but the fs layout is starting to come back to me.

All the other fs related commands are in /lib/fs/filesystem, e.g.
/lib/fs/ufs is where you will find fsck, clir, fsdb, etc...  They are
all there.

The reason with this layout is because of the large number of fs types
in SVR4.x (fs1k, fs2k, ufs, dos, etc).  So /usr/sbin/mount is actually
a wrapper that calls the right fs mount command.

Yes, a lot of this requires deep knowledge of how Solaris work.  A casual
user won't know this.

> /etc/mount and /etc/fsck are links to ../usr/sbin/mount
> and ../usr/sbin/fsck, a catch 22 in some cases.
> That's as good as saddle on a cow.

See above for my explanation.

> It's the manager breathing down my neck when whole department is waiting
> to bring a major file server, or a firewall for example, back online that
> matters. So /bin should never be on a separate partition no matter who
> argues otherwise, Ritchie or anybody else. That was proven at Sun and
> other places.

Umm, see above :-)

> There are so many inconsistencies in names, formats, and weird file
> locations that's not even funny. That's on the software side. Hardware is
> another matter.

What do you expect from a "merged" OS?  SystemV mostly "won" in the layout
and commands, BSD stuffs are relegated to the compatible dir /usr/ucb.  I
was not exactly happy either coming from severals year with SunOS... but
that is yet another off topic discussion ;-)

I am certainly not going to "defend" Solaris ;-)  Each and every OS has
warts.  Linux layout is not consistent either, it depends on the distro.
I got pissed switching between them and found that things has been moved...

> Shell alone is not the system saver, it just allows you to go around
> easily. It's other tools that are very important but not available (in
> Solaris) when a simple file like /etc/vfstab is messed up. Seen that too
> many times and listed at least two examples of files that are not where
> they should be.

Sure it is! ;-)  I've been in exactly the situation you described....
You do not need /etc/vfstab to mount fs.  So what if it is corrupted.
Use the tools available at hand to repair the fs, then rebuild vfstab
from the tools available, and you can actually do a lot with just shell
builtin commands and shell redirection.  Essentially it takes time and
I agree with you that having some commands available in /sbin will make
it easier, but not that one need a lot.

I won't go in all the details as this is a Linux list and not Solaris,
but I've learned quite a few tricks over similar episodes ;-), man,
nothing beat that "thrill" of being under the spotlight eh?

Tin Le
- ----
http://tin.le.org
Tin Le - tin at le.org
Firewall and Security Consulting


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQCVAgUBOZ40uxiIIbPkDHhBAQEsSgP/cc+cEnlZ0Big4RkhKKogPIQgau5s5/ko
HHoZdUUwdrlHoccBpzyvhNMjycSF78BcWLQ+dnJGRvdMxV9Wd4nibzd+ILpbA+cm
xAjgTKAFQrNvLonwuRZjj1tezKuxYfy5q1dSThx5ApbO1B30S1uZCOL4jQx6uD53
6VSNnquL+C8=
=dIGP
-----END PGP SIGNATURE-----