Some Solaris 2.x FAQs
How do I create slices/partitions?
Why are my new disks/tape drives not showing up in /dev?
I've forgotten my root password. How can I get it back?
How do I get to the “ok” prompt on my Solaris x86 machine?
How do I determine/force the speed/duplex of my ethernet interface?
How do I increase the size of a filesystem?
How do I send email attachments on the command line?
How do I automatically set my clock or keep it in sync?
How can I install Perl modules that need to be compiled under Solaris 8's perl?
How do I purge/rotate/archive my wtmpx file?
How do I get my Sun to request a specific hostname from a DHCP server?
What is the proper way to mix narrow and wide SCSI devices?
How do I disable that damned suspend power key?
Why should I not change root's default shell?
- How do I create slices/partitions?
- Use the format command.
- Run format.
- Select the drive you wish to modify.
- Enter ‘p’ for “partition”.
- Enter ‘p’ again for “print”. This will show you the current disk layout. Note that slice 2 should always be the entire span of the disk.
- Enter the number of the slice you wish to modify.
- You'll be prompted for a tag, flags, starting cylinder, and size.
- The tag is really irrelevant, but I usually set it to “usr” for most slices.
- The flags should be “wm” (writable,mountable) for all slices except swap slices, which should be “wu” (writable,unmountable).
- The starting cylinder can be determined by looking at the current slices and seeing where you need to fill in. If you're creating the initial slices on a disk or are otherwise starting anew, 0 is the appropriate starting cylinder.
- Size can be entered in blocks (‘b’), cylinders (‘c’), megabytes (‘m’), or gigabytes (‘g’). Note that ‘b’ is blocks, not bytes. Blocks are 512 bytes in size.
- Repeat the above step for each slice you wish to configure. Empty slices should be “unassigned”,“wm”,0,0. Make sure to set any formerly used slices this way, otherwise you might accidentally mount them and destroy data that they now “share” with other slices.
- When you're done, enter ‘l’ for “label”. This will write the slice scheme, or label, to the disk. You do not want to enter ‘s’ for “save”. This simply writes the scheme to a specified file somewhere on the currently mounted filesystems, and does not save it to the disk.
- You can then enter ‘q’ for “quit” twice to exit the program, or you can enter the command “disk” after the first ‘q’ to select a new drive to configure.
- Click here for a “screenshot”.
- Why are my new disks/tape drives not showing up in /dev?
- Because the operating system has not noticed that you attached them. Note that this may also apply to other sorts of new devices.
In Solaris 7 and earlier, run “drvconfig” followed by “disks”, “tapes”, “ports”, or “devlinks”. “drvconfig” scans the hardware and attaches drivers for everything it finds. The latter commands create the links in the /dev/ directory. “disks” and “tapes” can take the option ‘-C’ to get them to clean up currently unused links.
In Solaris 8, run “devfsadm”. This does everything that the above list of commands does. It can also take the ‘-C’ option to clean up the links. Solaris 8 also provides legacy links from the commands listed above to “devfsadm” to provide compatibility.
Under all versions of Solaris, you can also perform a “reconfiguration boot”. This is achieved by giving the booting kernel a ‘-r’ option or by creating the file “/reconfigure”. I suggest not using this option. For one thing, it requires you to reboot. It can also modify the path_to_inst information. Among other things, this can destroy a DiskSuite installation by making the drives swap places underneath what DiskSuite looks at.
- I've forgotten my root password. How can I get it back?
- If you have another account that can simulate root in some way (like with sudo or RBAC), you can use that to reset the password. This is fairly uncommon, though. You'll probably have to use the following method:
- Shut down your computer.
- Insert the Solaris Installation CDROM. (For Solaris 8, use the “Software 1 of 2” disc).
- Boot into the CDROM's single user mode. This boot will take longer than normal. You'll be presented with a root prompt.
- For Sparc machines, get to the “ok” prompt and enter “boot cdrom -s”
- For Intel machines, boot off the CDROM and enter “b -s” at the boot prompt
- Mount your real root partition. (“mount /dev/dsk/cXtXdXsX /mnt”)
- Remove root's password hash from the real /etc/shadow file, which is located underneath the mount point you just used. (“cp /mnt/etc/shadow /mnt/etc/shadow.bak ; sed -e 's/^root:[^:]*:/root::/' < /mnt/etc/shadow.bak > /mnt/etc/shadow”)
- Unmount the real root partition. (“umount /mnt”)
- Reboot the computer. Boot as normal — not using the CDROM.
- Immediately log in as root. There will be no password. Change root's password!
- How do I get to the “ok” prompt on my Solaris x86 machine?
- There's no “ok” prompt on Intel boxes. That's a feature of the Sparc architecture. The closest thing you have is the BIOS for the computer, and there's not any way to get to that except by rebooting.
- How do I determine/force the speed/duplex of my ethernet interface?
- By using the ndd command. First, you need to know the device name of your interface. In most (all?) cases, it's the same as the name of the interface, so your hme0 interface would be /dev/hme. Second, you need to know which instance of the interface you're interested in. This is the number after the interface name. So qfe2's instance number is 2.
In order to inspect the current values, run:
ndd -set /dev/<device> instance <instance>
ndd /dev/<device> link_speed
ndd /dev/<device> link_mode
Both link_speed and link_mode return either ‘1’ or ‘0’. For link_speed, ‘1’==100Mbps and ‘0’==10Mbps. For link_mode, ‘1’==full duplex and ‘0’==half duplex.
In order to force an interface's speed or duplex mode, use ndd to set the parameter:
ndd -set /dev/<device> instance <instance>
ndd -set /dev/<device> link_speed 1
ndd -set /dev/<device> link_mode 0
By default, speed and duplex are autonegotiated. If you force them, the remote end's autonegotiation will probably fail. You should probably force the other end as well.
To do this on startup, add the following to /etc/system:
set hme:hme_adv_100fdx_cap=1
set hme:hme_adv_100hdx_cap=0
set hme:hme_adv_10fdx_cap=0
set hme:hme_adv_10hdx_cap=0
set hme:hme_adv_autoneg_cap=0
- How do I increase the size of a filesystem?
- The first thing you need to realize is that before you can increase the size of the filesystem, you must increase the size of the device that it exists upon. That requires modifying the slice underneath the filesystem. The safe way to do this, basically, is to backup the filesystem, resize the slice, create a new filesystem on the slice, and restore the backup onto this new filesystem. The Solaris 2 FAQ claims that you can resize a filesystem on the fly, assuming you were able to resize the underlying slice in place. I consider this extremely dangerous and have never tried it. But it's there if you wish.
First, back up your filesystem. Remember that you can create backups on any device or file, not just tapes. If you do decide to backup to an empty slice or a file on another filesystem, make sure that you don't clobber it by manipulating that slice. Using a different disk might be safer.
Next, unmount the filesystem (if you didn't already do it as a part of your backup). If you're trying to increase the root, /usr, or /var filesystems (possibly amongst others), you cannot be running in a normal init state. I'd suggest booting off of your Solaris CDROM into single-user mode (boot cdrom -s).
Next, run format. This will allow you to view and modify your slices. (See the “How do I create slices?” section above for more info.) If you're very lucky, some unallocated space abuts the slice you want to expand. If you're lucky, some swap space abuts the slice you want to expand. You can steal from it, as long as the swap space is not currently “mounted” (use swap -d to remove it from the virtual memory system if you're still in a normal init state). If you're like the rest of us, the free space and swap space abut nothing useful and you're in for a hard process, as you'll have to back up and move around more filesystems. (You might want to consider buying a new drive at this point.) When you modify the slice, make sure that it doesn't overlap any other slices (except slice 2, which is intended to overlap the entire drive), or you'll corrupt the data on both slices and probably panic your OS.
Once you've resized the slice, create a new filesystem on it (newfs <device>). Also, if you've changed what slice any of the filesystems or swap spaces exist on, make sure you update your real /etc/vfstab before you reboot and/or remount.
Then just mount the new filesystem and restore the backup you made into it and reboot back to a normal init state if necessary. That was easy, wasn't it?
If you want to try to do it without backing up and restoring, you can follow these directions for resizing the underlying slice, but then use the resize on the fly method instead of backing up, creating a new filesystem, and restoring. I'd still suggest backing up, though.
- How do I send email attachments on the command line?
- First, let me address some ways that might work, but are, IMHO, incorrect. The first way is to just concatenate the file to the end of the message. This might work okay for text attachments, as long as the attachment is recognizable as such by context, but is, at best, ugly. Another way is to concatenate on a uuencoded copy of the attachment. There are actually some email clients that can understand this, probably due to some residual or intentional news-reading capability (where this sort of attachment is fairly common), but it's not really the right thing to do. If you're sure that your recipient can deal with one of these formats, then use them. Keep in mind, though, that your recipient might change in the future.
However, most mail readers these days are able to cope with MIME attachments. MIME specifies a sort of object container that can, and usually does, also contain some metadata about the object. It is easy to distunguish parts from other parts, and the metadata can help identify the type of data that is attached instead of trying to assume from context. However, there is no builtin command line utility to deal with sending (or, for that matter, receiving) MIME-encapsulated email. I suggest using nail, which is a modified version of the BSD command line client mail. There are many other such clients available in the free software community, but that one seems the most transparent.
- How do I automatically set my clock or keep it in sync?
- By using the ntp tools [x]ntpd and/or ntpdate. Both utilites require an external NTP server, lists of which can be found at the Timesync web site, along with more information on NTP itself.
Under Solaris, these utilities are configured using the /etc/inet/ntp.conf file.This is the configuration file for [x]ntpd, but Solaris parses it to get arguments to hand to ntpdate as well. Other than that, the use of ntp.conf is standard other than, possibly, its location and filename. The simplest configuration is to have the line “server <ntp-server>” as the only line in ntp.conf, where <ntp-server> is the IP address of the remote ntp server. By default, [x]ntpd expects there to be cryptographic authentication of the ntp server, but the Solaris startup scripts override theis by using [x]ntpd's ‘-A’ option.
Personally, I usually set up my LAN's router as an NTP client and NTP broadcast server. This way, I can just have the line “broadcastclient” in my ntp.conf.
In order to check the status of the [x]ntpd daemon, use the command “ntpq”, which will start an interactive session. The most important commands, IMHO, are ‘peers’, ‘associations’, and ‘pstatus’, which can be abbreviated ‘pe’, ‘as’, and ‘ps’, respectively. ‘peers’ will show you a summary list of all ntp peers, and may have flags indicating which peer it is syncing to (‘*’) and other things. ‘associations’ will list the same peers, not necessarily in the same order, and give you the association ID. This is used as an argument to the ‘pstatus’ command, which will show you how the relationship to the peer is progressing.
[x]ntpd takes quite a while to start up. It makes a pass through the 8 shown statuses once, then resets and does it again. Only then does it start to synchronize the clock. And then only if the current time is close to the time to be changed to. This is why using ntpdate first is a good idea, as it doesn't have that restriction.
- How can I install Perl modules that need to be compiled under Solaris 8's perl?
- Solaris 8 ships with perl, which is nice. However, the perl that ships is compiled with Sun's C compiler, which does not ship with the OS and comes at an additional price. If you try to install a perl module that needs to compile something, it won't work, because that perl is configured to compile things with the Sun compiler, and not gcc.
I have not fully tested this, but it seems to have worked for me. All you really need to do is get perl to use gcc and use flags appropriate to it, not to the Sun compiler. This information is contined within the /usr/perl5/5.00503/sun4-solaris/Config.pm. Here's a patch to Config.pm that seems to work for me.
- How do I purge/rotate/archive my wtmpx file?
- The wtmpx file, found at /var/adm/wtmpx, is a binary data file that keeps a log of logins. It's one of the files that Solaris doesn't rotate out by default. Many of the rest are easy to understand how to archive, as they are plain text and have no particular state, but wtmpx can be scary. First, wtmpx is not held open by any process. It is written to asynchronously by whatever processes need it. Second, while it does hold some state, you won't break anything by clearing it. At worst, you'll just see some users currently logged in that never appeared to log in in the first place. So, to be easy, you can just move it out of the way or delete it and create a new file. But it might be nice to hang onto some of the more recent data to keep track of what's been going on. Again, this isn't too hard when you've got a plain text log file, but we're dealing with binary data. So I've written a program that will keep the latest log entries, but fold the remainder off into a different wtmpx file (last can be given an argument to look at a different file, so this is not totally useless). I've not tested it extensively, but it seems to work fine. Plus, I've taken large portions of it from a program that's been floating around the net for a few years now, so it should be okay. Let me know if you find any bugs. Here's wtmpxarc.c.
- How do I get my Sun to request a specific hostname from a DHCP server?
- You can't. If your DHCP server can be configured to assign a hostname, then you can get it to do that, and the Solaris machine will accept it. I personally configure my DHCP server to assign names (but not IP addresses) based on hardware addresses for my Sun clients. If your DHCP server can't assign names (like many broadband gateways currently on the market), then you'll have to change the default “unknown” hostname to something more palatable. There's no configuration file to do this. You actually have to modify the startup scripts. In Solaris 8, change /etc/init.d/inetsvc, line 168, and /etc/init.d/network, line 298, to use whatever hostname you desire. You could also write a little configuration file à la the /etc/default files and use that to configure the hostname in the startup scripts instead of re-hardcoding it. If someone does that, feel free to send me a patch and I'll post it.
Starting with Solaris 8 7/01, you are supposed to be able to request a hostname from a DHCP server by modifying /etc/default/dhcpagent to set REQUEST_HOSTNAME to ``yes'' and then placing the line ``inet '' in /etc/hostname., which should otherwise be empty, in order to comply with DHCP setup. I've tried this once and it didn't work, but I didn't really follow up on it. I might have done something stupid. There's a little more information at docs.sun.com for How to Enable a Solaris Client to Request Specific Host Name.
- What is the proper way to mix narrow and wide SCSI devices?
- The basic issue is making sure that all devices are terminated properly. However, because of the variety of cables often used in making a SCSI chain, it can be hard to think clearly about where termination should happen or where it might be failing.
The easiest way to think of it is that you want to have one long SCSI chain that's tapped at points for access for the devices. Each end of the chain needs to be terminated. Also, note that the SCSI controller itself is just another SCSI device as far as the chain is concerned. (This is why, even if your single channel SCSI controller might have three connectors for compatibility's sake, you cannot have devices attached to all three connectors.) Also, almost all modern SCSI controllers will automatically terminate any of its connectors that have nothing attached to them and terminate only the wide portion if there is a narrow but not wide chain attached to it. Therefore, it's possible, for the purposes of cabling, to think of each portion of the chain on either side of the controller as a separate chain.
You also need to think of wide and narrow SCSI to be two separate parts of the chain. Any time one of them ends, it needs to be terminated. If you have a chain that is all wide or all narrow, then it's easy to just place the correct terminator at the end, but when you start mixing devices, it becomes more problematic.
In common internal SCSI connections, this is easy, because you've just got one wide SCSI cable that you have taps on to provide access to the devices. If one of the devices is narrow, you just use an internal SCSI adapter that just ignores the extra wires and taps into the narrow portion of the bus. The wide portion of the chain just passes by unimpeded.
For external chains, you want to emulate the internal paradigm as much as possible. This is complicated by the fact that extrernal cases seem to indicate that they are separate devices that can be daisy-chained. This is not really the case. When you connect multiple external devices together, you are really just extending the chain, not linking off of the previous device. Look inside most external SCSI cases and you'll see that the two connections are just connected by an internal SCSI cable with a tap on it. So the external cables and external cases are just extensions to the chain as a whole.
What this means is that, even though there are external SCSI cables that are wide-to-narrow cables, don't use them. They don't really work unless you're connecting only one device, and sometimes not even then. This is because they do nothing to try to terminate the wide portion of the chain. This also means that you cannot use external SCSI cases that have narrow connectors on a wide chain. There is an exception to this that I'll get to later.
So if you need to attach narrow SCSI devices to a wide chain, you need to get a wide external case and use an internal adapter to connect the device. This works, just like the internal connections described above, because it does not impede the wide portion of the chain, but just taps into the narrow portion of the whole chain. Then you have a wide chain complete to the end, and you can just use a wide terminator.
It's also possible to narrow the chain, but this requires that you have a terminator that will terminate only the wide portion of the chain. Some passthrough terminators will do this, but terminators are usually poorly documented if at all, and I wouldn't trust one to do it that did not explicitly state that it did, and even then I'd be suspicious. It's much easier to just make the entire chain wide. There are also some wide-to-narrow cables that claim they terminate the leftover porion of the chain, but most do not. Again, it's easier to deal with a completely wide chain.
You can also attach most wide devices to a narrow chain, and you don't really have to worry about this, but you'll lose the benefit of the wideness, which is a bus twice the width of a narrow chain, doubling theoretical throughput.
On the subject of terminators, alwyas use active terminators that have an LED on them. Active terminators work better than passive terminators and the LED gives you some indication that it's working. If you can find one, get a terminator that has separate wide and narrow indicator LEDs. This will give you even more assurance. I've never seen separate terminators that have this feature, only cases with built-in terminators. If you see one, let me know.
Also, some devices have jumpers on them that allow the device to terminate itself. Don't use this feature unless you're in a pinch. It's difficult to remember what devices have been terminated this way and which haven't, and there's not an easy way to see. If you have to move that device around, especially in an emergency, you can end up terminating a chain where you don't mean to and confusing yourself. The only exception to this is when the cases themselves have terminators built in. These usually have LED indicators, automatically disable themseleves when the chain is extended past it, and do not follow a particular SCSI device. In other words, you can still easily be sure where the chain is terminated.
In summary, use only wide cables and wide enclosures. If you must attach a narrow device, use an adapter within the SCSI case attached to the tap on the cable. This avoids cutting off the wide portion of the chain. Always use a wide terminator at the end of the chain.
- How do I disable that damned suspend power key?
- Try editing /etc/default/sys-suspend and change the PERMS variable to be defined as “-”. This should disallow suspends by anyone except root.
Alternately, edit /usr/openwin/lib/speckeysd.map. Comment out the (as of this writing) two lines that reference “SunPowerSwitch”. Restart your X server, including the dtlogin graphical login screen.
- Why should I not change root's default shell?
- To start, if you're using root's account enough that you really start to feel the need to use a different shell, then you're using root's account too much. Start using su or sudo or something similar. But with that out of the way, you still shouldn't change root's shell because it's a special shell compiled to be of use in emergency situations. The default shell for root is /sbin/sh, not /bin/sh, like all other users of the Bourne Shell. This version is statically linked so that it does not depend on any other file on your system in order to function. The normal Bourne Shell and all of the other shells on the system rely on many libraries that might have become corrupted leading to an emergency session. If you change root's shell to something else, you run the risk of locking root out of the system in such a situation. The last thing you want to have to do in an emergency is figure out why you can't log in and how to fix the problem. If you still feel that you must change root's shell (and, please, see my initial admonition), try to compile a new shell that is also statically linked.
|
|