Entries Tagged as 'Unix'

Tips and Tricks: Dedicated Server Wipe Commands

Most of the time when you have a dedicated server, you could be colocation or you could have a managed server. Unfortunately, if you own the equipment or buy used equipment, there could a chance that there is proprietary data that could do damage to your company if you left it on there without properly disposing of it. One of the easiest ways to wipe a drive remotely on a *nix based system though is with the command shred.

If you have a console or terminal connection, then you can issue:

shred -f -z -v -u /dev/sda

This will basically wipe a drive instead of doing your normal deletions where the data could possibly be recovered. The shred command is covered more in depth but in essence it overwrites the deleted sectors with other data which essentially destroys the deleted sectors. Probably a good idea for any system administrator that is maintaining servers remotely with no way to access them the drives themselves physically.

Reblog this post [with Zemanta]

Solaris: rebuilding hot swap drives

solaris.jpg For Solaris, when you hot swap drives in a server, sometimes it doesn’t autodetect itself. Yeah, I know. Annoying right?
Well for most of newer servers that use SCSI drives, you probably just have to run devfsadm as root. That should basically tell Solaris to check and look at which drives are where.
Unfortunately, some servers aren’t so easy. Such as the Enterprise E3500. This machine has fiber-channel drives and thus are more finicky. If devfsadm doesn’t work (and it probably will not), then you’ll need to add the drives in with luxadm. Unfortunately, there’s not an entirely easy way to do this. luxadm insert_device is one way to try it since it’s an interactive probe, but you still might need to know the syntax for the devices to actually add them in one by one.

Solaris: Be careful of migrations and replacements

solaris.jpg In a Solaris migration, you must be careful if you don’t have local access to a server. This actually goes for the same on linux servers but my concentration today is on Solaris itself.
Here if you do a server migration where the older one is A and a new scratch install is B, then the migration path would be: A -> B.
Assuming that both machines are up and running and both have their networks up, here’s how to replace A with B. Always assume path as A to B unless otherwise noted.

  1. Setup rsh or ssh copying ability for root.
  2. Copy over any data files stored in other places such as /opt. As server admin, I would assume that you know where these are stored.
  3. Copy /etc/passwd.
  4. Copy /etc/shadow over. Make sure it’s 400 permissions.
  5. Copy /home1/ directories over.
  6. Change permissions of the /home1/ directory on B by doing a for loop on /etc/passwd and using cut to pull the user name and applying it to a recursive chown for the /home1/ directories.
  7. Network change: edit /etc/hosts file and change B’s loghost line to match A’s.
  8. Network change: edit /etc/defaultrouter on B to match A.
  9. Possible point of failure: To change the network over, take note of the inet, netmask, and broadcast, and shutdown A. Then on B, do a ifconfig inet netmask broadcast && init 6

Hopefully after about ten minutes or so of agonizing waiting for Sun boxes to reboot, you’ll have B in replacement of A. Doing this remotely is often pretty scary since you could be thousands of miles away without local support and could take down your servers with a typo in a couple lines above. So instead of flying fingers, check, double check, and triple check. It just pays off in the end for a successful migration instead of having someone local rescratch box B for a do-over.

Solaris: Console loss fix after cold boot

solaris.jpg If you’re sitting at a server, there should be three lights on it. One LED is the power. The next is maintenance. The third is system (looks like a two arrows in a circular pattern).
Depending on the light blinking, it can tell you crazy things. Like whether or not your server is entirely hosed. On a Sun 3500, here are the LED codes:
Left LED (green)
On — the power supply is delivering DC power
Middle LED (yellow)
On flashing — (first 60 seconds of AC power) self tests are running
Off — (after self tests end) no hardware failures detected
On — (after self tests end) hardware failure was detected
Right LED (green)
Off — (first 60 seconds of AC power) self tests are running
On flashing — (after self tests end) system is running
Off — (after self tests end) system cannot run; repair is needed
I can tell you that the issue I ran into was an Left: On, Middle: Off, Right: Flashing. According to the chart above, the server is working right? But it was after a cold boot because the console froze on a probe-scsi-all. And the console would not come back up. After spending much frustrated time trying to figure out how to make it connect again, I did the following:
Power cycle console.
Yup. That’s it. That resets the console to work with the server. Go figure. And it seems that not many people run into this issue since I have yet to see a fix documented somewhere for this. Oh well. Good times.

Solaris: Changing an IP address

solaris.jpg Changing an IP address is a little more difficult than your usual commands in linux. At least if you want to change it permanently.
If you just use the ifconfig command, that is only a temporary solution. It will automatically reset itself upon a reboot. So you have to do that and also edit /etc/hosts, change your /etc/defaultrouter (this is the file that points to your router or whatever is sending your broadcast).
Usually this is enough, but in Solaris 9 and up, you might need to edit your /etc/inet/ipnodes if it’s been changed before. Also, if you use VLSM (variable length subnet masks), then you’ll also need to edit /etc/netmasks.
No one ever said Unix was easier. Just more stable.


Spice is a circuit simulator for the Unix platform to analyze and design IC boards without having to build and design those circuits. This piece of software has been around for a while and I totally forgot that it was freely available for not only education but actually as design utility.
There are others out there that are commercial and have more functionality and such, but overall, you can’t beat the free from U.C. Berkeley. I remember spending many late night hours in the lab with this piece of software and if you’re looking for something to help do IC design, don’t forget some of your old college software friends.

Trend Micro HouseCall

housecall.gif When Trend Micro first came out with HouseCall, this online antivirus scanner was only IE enabled. Very annoying, but also pretty useful considering it was one of the few if not only online enabled antivirus scanners. This meant that as long as you had an Internet connection, you could work on an infected system without having to worry if your rescue media had the latest and greatest antivirus definitions.
Well, they’ve come a long ways. now support Firefox and even MacOSX, it now has a lot better support. In fact, it can even scan in linux and Solaris. Goodness gracious. Unix online virus scan? Wow. Maybe Clam has a bit catching up to do.
While it now does have the two different engines that run (the ActiveX one that used to be the only one) ActiveX and Java, I have to say that there are a couple cons to this product. The first would be the fact that it doesn’t seem to have support for Firefox versions 2 or later. What’s with that? Firefox has got to be one of the more dominant browser types. And what about Opera or Safari? Well… no matter. The second is that if I remember correctly with the older ActiveX engine, it took a dang long time to load. Why didn’t they just implement it directly in the Java engine and throw away the ActiveX? java does actually work in Windows you know.
Regardless? I do love recommending this when someone thinks they are in need of antivirus and I’m not there to help them. It’s easy enough to run yourself and there’s less worries that there will be a virus smart enough to actually detect a Java or ActiveX engine antivirus scanner. Perhaps they might, but the likelihood would be more so on an attack of the offline scanners if anything. Just take a look and bookmark it for the next time you might need it.

Solaris: Adding a new user

solaris.jpg User additions are no different in Solaris. The useradd command is what’s used to do the addition (must be done as the root user).
The -g flag defines which group you’re adding the user into, and the -d flag defines the user’s home directory. Obviously the last part is the username that you’re trying to add. Also, always remember to use the -m flag. This flag creates the user’s initial directory structure from the skeleton directory, and gives it the right permissions. If you forget to do this, you’ll have to do it manually.
# useradd -g users -m -d /home/export/username username

Solaris: changing a user’s shell

solaris.jpg This is another system administrative command that doesn’t really change from linux.
If you take a look at the command passwd, it doesn’t just change passwords. In fact, if you do:
passwd -e username
You will be shown the user’s current shell, and be asked for a new shell. Most people just use the default one for the system which usually is either ksh or bash, but to each their own on what you like. There are also ways to actually change the shell itself through the .profile upon login but that’s for another day.

Solaris: Adding a default route

solaris.jpg One of the things to get internet working in Solaris, is to edit the defaultrouter file. Usually it’s one single line that has your gateway address in it.
So if you add this to /etc/defaultrouter, you should be up and running. One of the basic rookie mistakes is to not set this file and then hunt all over the place trying to figure out why networking doesn’t work with the new box. Believe me. I’ve done it. It doesn’t take much. So one of the first things to check is always make sure that there is an ip address in defaultrouter and make sure that it is actually your gateway.