Temporary beaglebros.com site |
Also enjoy this site over IPv6! BeagleBros CA |
Someone also suggested that shell functions might be handy. So here's one for ksh and zsh, and one for bash (have I mentioned how much I hate bash?). If you can figure out how to do an if/then/else in a csh alias, let me know, and I'll be happy to put that up here as well.
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.
In order to inspect the current values, run:
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.ndd -set /dev/<device> instance <instance> ndd /dev/<device> link_speed ndd /dev/<device> link_mode
In order to force an interface's speed or duplex mode, use ndd to set the parameter:
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.ndd -set /dev/<device> instance <instance> ndd -set /dev/<device> link_speed 1 ndd -set /dev/<device> link_mode 0
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
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.
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.
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.
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.
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.
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.
javascript:qtext=document.selection.createRange().text;if(!qtext){void(qtext=prompt('Enter word to find in Merriam-Webster Dictionary:',''))}if(qtext)void(window.open('http://www.m-w.com/cgi-bin/dictionary?'+escape(qtext)))
javascript:qtext=document.selection.createRange().text;if(!qtext){void(qtext=prompt('Enter word to find at Dictionary.com:',''))}if(qtext)void(window.open('http://www.dictionary.com/cgi-bin/dict.pl?term='+escape(qtext)))