Occasionally I like to access Telnet BBS to re-live my youth.  Telnet works fine, but once you want to start doing file transfers, etc., it quickly becomes limited.

Enter “modemu”.

ModemU adds Telnet capability to a comm program by redirecting Telnet I/O to a PTY.  Basically, the Communications Program doesn’t really have any clue that it’s not a serial port.

You can get ModemU from Good ‘ol Sunsite by clicking here.

ftp://sunsite.unc.edu/pub/linux/apps/serialcomm/dialout/modemu-0.0.1.tar.gz

It compiled just fine on my Ubuntu 9.04 workstation after installing flex.  Once compiled, you can  use it as a stand-alone client, which doesn’t serve much purpose, if you ask me.

However, this is the way I used it with minicom:

$ modemu -c “minicom -p %s”

This should work with other communications program, as long as you can pass in the port to use.  ModemU, after creating the virtual PTY, passes in the PTY # to the command specified via the %s variable substitution.

Tada!

Once in minicom, you can do the following to connect to your favorite telnet systems:

atd”hostname

CONNECT

Welcome to….

To disconnect, once you exit your system, you will receive a “NO CARRIER” message.  Then, you can exit with at%q, or exit with your communications program.

* Main * 0:00:03 [2] DOVE-Net [1] General: /O

NO CARRIER
at%q

There you have it.  Simple Telnet<->Modem Emulation in Linux.  This should also work on other UNIXes, but your milage my vary.

More »

Looking through my ~/bin directory, which is a collection of some of the scripts I’ve written going back to the wee days of me playing with UNIX.

I found this script, named “findjosh”.

#!/bin/sh

joshsip=`lynx -dump http://www.cae.wisc.edu/~resch/ip.txt | head -3 | tail -1`
case $? in
0) echo “Josh’s IP Address is presently “$joshsip;;
1) echo “..There was an error…”;;
esac

I know, it’s really simple, but I must have used this script a couple of times a day.   A little explanation.  This script was written in the very early 90’s.   This time was way before Instant Messaging that we know today.  To chat with friends back then, we often utilized the UNIX “Talk” facility, and later, Windows programs that provided the same functionality.

Instead of having a directory of people, or the ability to just punch in their “handle”, to chat with a friend, you had to know their IP address.  This would be easy, but even back then, they often changed quite often.

My friend Josh, as well as other friends from their era, resorted to many methods to let people know where they were.   In the case of Josh, he published his current IP address into a text file called ip.txt.  So whether he was in his dorm room, or on one of the numerous HP or SUN workstations, this made it easier to find him rather than using the “finger” command to hundreds of UNIX workstations!

Another version of this script that I was playing with is below:

#!/bin/sh

lynx -dump http://www.cae.wisc.edu/~resch/ip.txt > ~/bin/findjosh.tmp
cat ~/bin/findjosh.tmp | head -3 | tail -1

I wasn’t surprised to find a findjosh.tmp file in my bin directory:

$ cat findjosh.tmp

Josh last logged into the following address-
144.92.181.221
F18x-xxx.net.wisc.edu (fill in the x’s yourself)
-
Last updated-
08-31-1996 21:33:29

Does anyone remember doing stuff like this to track down your friends?  What methods did you use?

More »

This works great for redundancy, but with a little planning, you can accomplish simple load-balancing too.

Let’s consider a HPUX system which has two paths to the SAN, and two 50GB LUNS present to the server. The controllers are c17 and c19 and the two disks are t0d0 and t0d1. With PV-Links, you will thus have the following disks detected by the operating system:

/dev/dsk/c17t0d0
/dev/dsk/c17t0d1
/dev/dsk/c19t0d0
/dev/dsk/c19t0d1

Both c17t0d0 and c19t0d0 are the same LUN on the SAN, and also c17t0d1 and c19t0d1. With me so far?

The trick is, when adding these to a new volume group, you want to stagger them so that every disk you add, alternates between using the two controllers.

Therefore, I add them like this:

vgcreate vgTESTVG /dev/dsk/c17t0d0 /dev/dsk/c19t0d0
vgextend vgTESTVG /dev/dsk/c19t0d1 /dev/dsk/c17t0d1

You will end up with a vgdisplay -v /dev/vgTESTVG that looks like:

.
.
.
— Physical volumes —
PV Name /dev/dsk/c17t0d0
PV Name /dev/dsk/c19t0d0 Alternate Link
PV Status available
Total PE 12797
Free PE 12797
Autoswitch On
Proactive Polling On

PV Name /dev/dsk/c19t0d1
PV Name /dev/dsk/c17t0d1 Alternate Link
PV Status available
Total PE 12797
Free PE 12797
Autoswitch On
Proactive Polling On

Therefore, all disk access to the first disk will go down the c17 controller, and all access to the second disk will go down the c19 controller. You would then continue the pattern to add additional disks.

Keep in mind, that this is very basic load-balancing,  and might not even qualify as true load-balancing.  There are much better products out there that do a much better job (Powerpath, Veritias Storage Foundation, etc.).

However, if you only need very basic load balancing, and want to save a few dimes, this might work for you.

More »

This request is often used for testing software releases, deployments, etc.

I’ve use this script at least a dozen times per month, and haven’t really fine tuned it, or improved it at all.  I still create the volume group manually, and add the physical disks.

# Loop through each logical volume name (They all should start with l),
# get the size, and then create in the new VG.

for i in `ls -1 /dev/vgORIGINALVG/l*`
do
MB=`lvdisplay /dev/vgORIGINALVG/$i | grep “LV Size” | cut -c23-40`
lvcreate -n $i -L $MB /dev/vgNEWVG
done

Real basic, but saves quit a bit of time.  I am merely keeping everything default, and am not taking into consideration any special settings.  Again, these are generally used for testing, and then removed — at least in my environment. So it’s not really a true “clone”.

I’m sure there are countless otherways to accomplish this, and maybe even an easier way, but I whipped this up one day when I had a request to clone 3 or 4 VG’s.

This might work on other LVM systems with some tweaking.

More »

A reboot would have fixed this — but I don’t like rebooting UNIX/Linux unless it’s absolutely necessary (and it rarely is).

The first thing I noticed is that doing an ioscan -fnC tape showed “NO_HW” on one of our IBM tape drives.   NO_HW indicates the devices has dissapeared, and was there before.

Next, I forced HPUX to rescan for new devices with the insf command:

# insf -e -C tape

The “-e” option tells insf to reinstall the special files for pseudo-drivers and existing devices.   The “-C tape” told insf to only match devices that belonged to the tape class.   Since I like to narrow down any impact, I prefer to work with one class at a time.

Once this command was completed, I now saw the tape drive that was “NO_HW” earlier, appear in the ioscan output.

However, the one that went missing was still there at the old patch.   Now, again, a reboot would fix this…. But do we want to do that?  NO. You don’t.

The rmsf command comes to the rescue here.  Let’s say the one missing (NO_HW) was at the following hardware path:  0/2/0/0.197.12.255.1.8.0, the following command would remove it.

# rmsf -H 0/2/0/0.197.12.255.1.8.0

No reboot necessary.  There also ways to accomplish the same tasks under other OSes, and I will cover those in future posts.

More »

I’d like to introduce the newest UNIX guy into my family…   Meet my new Son, Dexter…

http://www.flickr.com/photos/47643618@N00/sets/72157622188318531/

Born 9:28am on 9/8/9.  8 pounds, 14 ounces.  20 1/2  Inches.

More »

No, she is O.K. now, and is back up and running.  I am saddened because this server had been up for 826 days and had been a braggin’ point for me quite sometime.  Sure, I’ve seen servers that have been up longer –but never has a machine at one of my “at home” Data Centers /Labs been up this long.

She was connected with redundant power supplies, with each one going to a separate commercial UPS, and each of those going to separate breakers, with each of those going to separate sides of the incoming 220 service.   There wasn’t much else I could have done to keep Nattie’s power redundant — short of a second power company feed. 

Right now, I am at the whim of the batteries in the UPS which surprisingly kept everything (several other servers, tape library, 4 switches, VPN Concentrator, Secure Computing Firewall, Backup Server, etc.) on for about an hour.   I’m definitely thinking a whole-house generator is going to be on my shopping list in the future!

10:09:03 up 800 days, 9:51, 3 users, load average: 0.33, 0.76, 0.62

(Uptime from July 13th, 2009, when I celebrated 800 days)

Well, at least now I have a good opportunity to add some additional memory and make a few other hardware changes!

More »

I was thinking… I wonder if they have a Virtual Appliance for people to play with it before buying one. A Google search later, I found what I was looking for.

Enter the Google Search Appliance Virtual Edition.  This is distributed by Google as a VMware Virtual Machine.   Within about an hour, I had my Virtual GSA up and running and indexing all of my websites including some sites that had NTLM based protected content.   Pretty neat.  It would have been much quicker, but the decompress process (p7zip) took like 30 minutes on a Core 2 Quad Ubuntu workstation, leaving me with about a 40GB VMDK.

The Virtual Edition is meant for development use.  Legally, you are not allowed to use it for any production use.  Plus, it’s limited to 50,000 indexed files.   I would highly recommend a real Google Mini search appliance.  But if you already have one,  the Virtual Edition would be great for testing website search integration changes before implementing them on your real GSA.  And, if you are thinking about getting one, trying out the Virtual Edition will allow you to get your feet wet, and experiment with it’s features.

I would strongly recommend giving it plenty of Virtual Resources when you fire this up.  I starved mine, at first, from the resources it wanted, and it performed a little sluggishly (to be expected).

Also, after booting it up, make sure you wait a bit before trying to connect to it.  It seemed to take a good 5 to 10 minutes before I could point a browser at it to connect — again, this could be related to me not giving it much memory.  I gave it 1GB, and the requirements said 3GB was the minimum needed.

Enjoy.

More »

So, for your enjoyment, I’ve summarized each command below.  Having everything on one page will save you the trouble of going through each one doing “help command” to find out what each does! (Which is what I seem to have to do every time I hop on one of these and try to remember which command does what).

The Command Line Interface (CLI) is always handy, and usually the first place I check out. It’s especially handy in a clustered environment as you can login to one of your NAS heads, and then telnet from there to the heartbeat interface of the other NAS head. This is useful when your volumes are still failed over to the surviving NAS head along with it’s main IP address.

The 5320’s “menu” command will bring up a nice menu that lets you do most (all?) of the things you can do in the GUI.

One other note about the GUI. It appears that only one person can be logged in at a time. So if you are in it, and keep getting disconnected, it’s probably because someone else is trying to access it too. What you are seeing is a ping-pong effect of two (or more) people getting kicked out, and logging back in. Utilizing the CLI over telnet or SSH does not have this problem.

I may go into details about some of these commands in the future.

Enjoy!

More »

HPUX

# getconf KERNEL_BITS
64

This will tell you if your currently running kernel is 64 bits or 32 bits.  It returns the number of bits used by the kernel for pointer and long data types.  Current values include 32 and 64.

# getconf HW_32_64_CAPABLE
1

Returns which kernel is supported on the hardware.

You can also test this with a short C program:

# cat check3264.c
#include <stdio.h>
#include <unistd.h>

main()
{
long ret = sysconf(_SC_HW_32_64_CAPABLE);

if (_SYSTEM_SUPPORTS_ILP32OS(ret) != 0) {
printf(”system supports 32-bit OS\n”);
}

if (_SYSTEM_SUPPORTS_LP64OS(ret) != 0) {
printf(”system supports 64-bit OS\n”);
}
}
# cc check3264.c
# ./a.out
system supports 64-bit OS
#

In this example, we see the test system, an HP L2000-36 running HPUX 11.11, only supports a 64 bit HPUX Kernel.

# getconf HW_CPU_SUPP_BITS
64

This will show you if the CPU’s are capable of running 32, 64, or 32/64 bit kernels.

Solaris

For solaris, the isainfo -v should, at least for versions past 2.6,  show you want you need:

# isainfo -v
32-bit i386 applications

This may also say “sparc” if you are running on the sparc architecture. If you were on a 64 bit system, you would see something like this:

64-bit sparcv9 applications
32-bit sparc applications

This would be telling you that you are running a 64 bit kernel and can run either 64-bit sparcv9 applications, or 32-bit sparc applications.

To determine the cpu’s bit size capabilities, isainfo -b does the trick here too:

# isainfo -b
64

AIX

For AIX, we will use the bootinfo command.

bootinfo -y
32

This show is the hardware is 32 bit or 64 capable.

bootinfo -K
32

Shows the running kernel’s bit size.

Linux

For linux, we will look at the cpuinfo from /proc. Here, we are mainly interested in the “flags” for the CPU’s:

# cat /proc/cpuinfo | grep -i flags
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm

We are interested in three values in the output, as they indicate the bit size capabilities of the CPU:

16 Bit = rm (Real Mode)
32 Bit = tm (Transparent Mode)
64 Bit = lm (Long Mode)

This doesn’t necessarily mean the Motherboard is capable of 64 bit.

To determine the bit size of your running kernel, you can also use getconf, similar to HPUX, to find this info:

# getconf LONG_BIT
64

This shows that my kernel is running 64 bit.

More »