Even the most experienced Linux admin can sometimes feel frustrated trying to do a simple task in a new *nix environment like Solaris or BSD. This quick tutorial should ease the transition and clarify the most common terminologies in Solaris 10.
This is not a run of the mill n00b intro to a Unix OS. This tutorial is intended for seasoned Linux admins and it does not waste time on explaining the obvious.
Summary:
- Filesystem Layout
- High level directories under / and a detailed look at /usr
- The Automounter
- The automounter is a method of mounting NFS shares “on demand”.
- Sudo and Root
- There is no
- NFS Shares
- NFS mount points are listed in /etc/dfs/dfstab.
- Process Monitoring
- No top in Solaris, but instead there is prstat.
- Package Management
- “.pkg” files for packages and pkg-get in place of apt-get.
- Managing Services
- Equivalent of RC scripts and ways to start/stop/restart services
- Disk Management
- Volume management, Mount points, Formatting disks etc
A fantastic piece, expecially for those just trying the latest OpenSolaris release…
Ben Rockwood is one of the people in the OpenSolaris community who I have a lot of respect for
Looking at the directory and utility filenames, you can clearly see the old mechanical teletype origins of BSD systems. Back then, pressing each key required quite a bit of physical effort, which is why the commands and directory names were so short. The shell back then obviously didn’t have auto-completion like modern shells do today.
And this silly legacy lives on, confusing all new users with arcane syntax.
I would consider myself a “casual” unixer at best and I don’t have too much trouble understanding what you describe as “arcane syntax”…
Yeah it would be nice if we could rename “src” to “Source” and “tmp” to “Temporary” but losing the backwards compatability that this brings would not be worth it. Perhaps some sort of abstraction within gnome/kde to hide the dark art you speak of would be more appropriate. anyone playing in the shell should at least have a basic understanding of the FHS.
It’s not completely silly; most people aren’t fast typers, and giving them long, wordy commands while easier to understand is going to slow them down quite a bit.
With that said, it’s also a compatibility issue. Those short, terse commands are coded in hundreds of thousands of programs across the software spectrum.
Changing any of them will break a lot of software.
Finally, most users that would have problems with these commands are going to be more comfortable with a GUI anyway, so I don’t see the concern…
And don’t forget about specifying paths in configuration files or environment variables. I’d much rather have /usr/lib rather than /user/libraries, or whatever it would become. The FHS may look arcane, but it does have a method to its madness. True, it is a hold over from the beginning days of UNIX but I wouldn’t call that a bad thing. Not all thirty-year-old concepts are bad
.
NB: usr != user; usr = UNIX system resources, so the path would be /UNIX_System_Resources/Libraries. You may add spaces and uppercase letters because it’s possible. 🙂
No, no, no… /usr is (or was) an abbreviation for /user as it was the location for home directories. The silly Unix System Resources thing is fairly recent.
Yes, I admit it’s a valid interpretation. Some UNIX documentation mentions /usr as being the place for “user binaries (and libraries)”. Maybe you could give an evidence (from a publication or a manual) where your interpretation is stated?
For example, it’s common on FreeBSD to have the home directories in /usr/home (with a symlink /home@ -> usr/home). On Solaris, as mentioned, you will usually find /export/home instead.
Furthermore: http://www.osnews.com/thread?37861
What /usr stands for seems to have been argued for ages now. Does it really matter in the long haul? I’ve always interpreted it as “user” for a few reasons:
1. It’s where non-essential binaries are placed, i.e. user binaries, though that’s not strictly literal anymore. The unix system resources would be in / (/bin, /etc, /lib, /sbin). Without them, you don’t have a UNIX system. Therefore, they are the UNIX system resources. /usr was meant to be nonessential, though most Linux distros do not hold to this any longer. BSD and Solaris do, however.
2. /usr/home was once a very common place to store user data, rather than simply /home. This was particularly common with dial-up ISPs’ shell accounts running BSD/OS.
So, that’s why I’ve always seen it as “user.”
Thank you for this explaination.
The system resources of the UNIX operating system usually are located on the root partition, so they are availabe under conditions where only / is mounted ro and no other partitions can be accessed, still leaving the operator with a functional system for diagnostics, repair and maintenance.
When you extend what the UNIX system should be, you could consider the content of /usr to belong to it, too.
I see, interesting. Out of curiosity, I’ll see how other UNIX OSes keep this.
As I said, completely valid, but finally, I think both interpretations are understandable and okay. Even from the point of the vendor’s documentation of different UNIX systems, it seems that there are both points of view available.
I don’t know how it is in other countries, but at least in Germany it’s common to pronounce /usr as “user” (as in “usr local lib X elf”).
Finally, it doesn’t matter because in the past, there were different explainations, and in present, there are different interpretations.
Even if you are a fast typer, simple, short directory names have advantages–especially when going to a directory that’s buried pretty deep within the filesystem. I cringe at the thought of having to type a typical Windows directory out vs. a typical UNIX counterpart.
C:\Documents and Settings\User Name\Application Data
vs…
/home/username (dot files and dot directories within usually)
C:\Documents and Settings\User Name\My Documents
vs…
/home/username
Seriously, couldn’t they just keep C:\My Documents (which is where it was in win9x)?!?
Plus numerous other “My” folders (Music, Pictures, Videos, etc.) which are subdirectories in the My Documents folder, as if that one wasn’t long enough already… and as if such media are actually some form of “document” in the first place.
And, just gotta love how they chose “Program Files” instead of the much simpler and more to-the-point “Programs.” And how they moved C:\Windows\TEMP (which was a decent location) to C:\Documents and Settings\User Name\Local Settings\Temp (come on!).
But possibly nothing beats… drumroll…
C:\WINDOWS\system32\drivers\etc\HOSTS (huh? drivers? a system folder within a system folder? it almost seems like they’re trying to *hide* this file!)
I preferred its original location in win9x as well, C:\WINDOWS\HOSTS, but /etc/hosts above all.
I’ll take my /bin, /sbin, /tmp, /etc any day over the longer Windows ones (which, in many ways, make no sense). Especially over some of those rearrangements in newer, NT-based Windows versions.
Plus… if there’s one thing I absolutely HATE when it comes to filesystem locations, it’s spaces. And Windows’ filesystem is full of them.
Well, they couldn’t very well keep it c:\My Documents if they wanted to have separate user accounts with separate documents folders. Bare in mind that 9x was not multi-user at all, where as NT, and consequently all current versions of Windows, are.
That being said, I agree completely with the rest of your post. Long paths can be an absolute nightmare, especially in the windows style–and that’s leaving out drive letters, don’t even get me started on those (although that’s not something MS can be blaimed for). What really gets me is when you need to run POSIX-compliant software under Windows, and it doesn’t understand windows paths. Very annoying, thank you for that Windows.
I don’t mind the way OS X does it. The path names are a bit long, but they are straight to the point. /Applications, /System, /Users/$NAME/Documents, etc. Of course, these are on top of the FHS, which for some people might be confusing. I just look at it like this: the FHS for the UNIX underpinnings and software, and the OS X folder names for the GUI and everything related to it. This is not to say it’s the cleanest way of organizing the filesystem, it isn’t. But at least it does make sense, unlike some of the Windows file locations, and any software–be it command-line or GUI, POSIX or OS X-specific, can open whatever path is needed. No fiddling about like there is on Windows.
There are much cleaner ways of organizing the filesystem. Trouble is, they inevitably lead to longer paths, though not necessarily long directory names.
True, for whatever reason that didn’t even go through my head. However, I still think that “Documents and Settings” is overkill.
I don’t have much experience with Mac OS X, which is why I said nothing about it. However, from what I’ve read about its filesystem, I would have to agree that it’s not that bad of a layout. I have tried GoboLinux though (very briefly), which attempts to do similar things to the filesystem as Apple did with OS X, and while I wouldn’t want it to be adopted by all distros, it *is* nice that it’s being worked on as a potential alternative for anyone who wants it.
Symbolic links may solve that “problem”.
<========[[[){)o.;[>~
Zenja, it comes back to the old story of ‘easy to use at first’ vs ‘easy to use’. Sure long verbose names might help new users to get to grips with the system, but would you really want to be forced to use them everyday. Personally I would rather invest a little mental effort into remembering the short mnemonic directory and command names – you don’t even need to know what they mean just what they are likely to contain.
Sure keystrokes may come cheap now that we aren’t using teletypes and and have shell completion, however that isn’t the only benefit of short mnemonic names. What about screen space and readability (i.e. being able to quickly read the screen). Take the following that I might use on my SUSE webserver (using Plesk):
/srv/www/vhosts/domain.name/conf/vhost.conf
Now compare it a with a more verbose equivalent:
/Server_Files/Web_Server/Virtual_Hosts/domain.name/Configuration_Files /Plesk_Virtual_Host_Apache_Configuration_Override_File
Sure the second one is more descriptive, however it isn’t a great deal more meaningful. The amount of time it will take you to read and comprehend is much greater (IMHO). Also if you are on a small terminal, every command you type will be spread across several lines.
You might want to review your history. BSD was much, much more verbose than SYSV and was the first time I remember seeing command-line options having more than one character.
I have never heard that. I thought I read it was because they had to send them over 300 Baud modem lines or whatever they had back then.
Be aware that some of this information is out of date. This information was posted on Ben’s site over two years ago.
That being said I’ve always enjoyed Ben’s site, lots of useful info there.
…is here: http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sektion=0&m…
Here, here! Why, oh why, oh why, couldn’t the Linux folks pick up where BSD left off, instead of trying to (poorly) emulate SysV? The FHS would be so much simpler to understand.
/ is the OS
/usr is apps shipped with the OS
/usr/local is for apps installed via the package manager
/opt is everything else, if you don’t want to pollute /usr/local
/home is for user directories
Does it get any simpler?
Just one of the many reasons I always choose *BSD over Linux where possible, and only choose Linux if *BSD is lacking an essential driver or application. I’ve always found BSD to be clean, and not just in the filesystem aspect. The overall system is just much better integrated and gives the feel of a well-crafted piece of work. But we don’t need anymore *BSD vs Linux vs SysV vs Solaris flame wars. BSD is what _I_ prefer, that’s all.
But BSD doesnt have a good ZFS implementation yet. Nor DTrace. :o)
ZFS is available in FreeBSD 7.0, is improved in 7.1, and almost equal to OpenSolaris in 8-CURRENT. And DTrace is available in 7.1.
We’re even using ZFS in production on our backup server, which does an rsync of 82 Linux and FreeBSD servers every night, using snapshots for daily backups, and zfs send/recv to create an off-site replica.
Article is dated 06 Mar ’06 and anybody interested in a transition to (Open)Solaris has already read it.
This site should be renamed to “OS olds”.