Recently in vi Category

I've had my $10 Sparcstation 20 sitting on the desk for awhile. I don't have a monitor, mouse or keyboard hooked up, so I've been running it over the serial port, which was surprisingly easy to do, via my Windows box and PuTTY, which provides for connections over SSH on the network or via the serial port. (I've also used Tera Term and Minicom (the latter in Linux), as well as the cu utility in Linux and OpenBSD to facilitate serial connection to this box.)

Thus far I've had trouble loading and running just about everything on this 1995-era Sparc. The easiest system thus far to install has been OpenBSD. It boots and installs from a floppy, with the filesets coming over the network, with little trouble.

The only problem with OpenBSD is that many of the apps I want on the box are not in the Sparc 32 packages repository, which has many fewer prebuilt binary packages than are available for 64-bit Sparc systems. Thus, for things like Web browsers that aren't Dillio (which runs great under OpenBSD on the Sparc 20, by the way), I need to use ports. And every time I try to install one of those apps (so far Seamonkey, Firefox and the Geany text editor) from ports, the build fails.

Maybe that's why these apps aren't in packages: They won't build in Sparc 32.

I tried to install Debian Etch. The floppies I made wouldn't boot on the Sparc, and the CD stalls at loading the esp driver for the CD. I've seen this in bug reports, but if you can't get the installer to work, who knows what else lurks in Debian for Sparc 32?

Now I'm trying NetBSD 4.0.1 on CD. I would've tried the floppies there, but I could barely understand how to make them. (You need two, and I couldn't get the first one to boot on the box.) As far as making a bootable install floppy, OpenBSD is the only OS with which I've been able to do that successfully.

But NetBSD for Sparc 32 had many, many binary packages, and I actually have a good chance of setting up a nice box ... if I can load the OS.

Once I got the CD drive hooked up, my first try with the NetBSD CD ended with read errors when pulling the filesets off the disc.

But since I was able to boot the system from the NetBSD CD and then start the install process (which is extremely clear and straightforward, by the way), I opted to pull the filesets over ftp.

That worked, and now I'm booting into NetBSD 4.0.1, still over the serial port.

The box works. I had trouble with the terminal type, which defaulted to sun. That doesn't play well with the PuTTY on the serial port.

When I installed the system, I chose the Bash shell for root. I probably should've used the ksh, which which I'm becoming more familiar with in OpenBSD, but since I had Bash, this is how I set the terminal type in the console:

# TERM=vt100 ; export TERM

After changing the terminal type at the Bash prompt, I was then able to use vi to get into /etc/ttys and change that terminal type from sun to vt100 without the whole file blowing up — something that has bitten me you know where in my previous OpenBSD install on the Sparc. Morale of story: If you have the choice to set a terminal type and aren't using the attached Sun keyboard and monitor (or another Sun over the serial port), DON'T CHOOSE SUN AS YOUR TERMINAL TYPE. Use VT100, VT220, or whatever it is your terminal software emulates.

Without this change, you might be OK at a prompt, but bad things will happen in vi.

Tomorrow I'll try to control the box over SSH instead of the serial port and see if I can run X over SSH (and maybe ... finally ... get my $5 adapter to hook up a VGA monitor to the Sparc).

Right now, if I didn't need any applications from the ports tree, OpenBSD would run very well on the Sparc 20. But if I can manage to get a "real" Web browser (Firefox or Seamonkey) and my preferred X text editor (Geany) on the box with NetBSD packages, I'll stick with NetBSD and hopefully have a little fun with my 50 MHz Sparc 20.

Photo at top right: Thanks to HolyCowPie! for the "Stack of Sparcs" image. If you're in Omaha, Neb., or near it, HolyCowPie! will fix your hardware for $35 an hour with a two-hour cap, meaning you won't pay more than $70 — a stake in the collective heart of the pricier, Best Buy-owned Geek Squad.

I did a Debian Etch install on one of my test machine drives recently, and today I added the openssh-server package so I could play around with PuTTY and Xming.

Once I installed openssh-server (I used Synaptic, in case you were wondering), using PuTTY to start the connection, I was asked whether or not I expected the encryption key to change (I was, since this is the Debian install, not OpenBSD, which I've been using until now).

One bonus of using this Debian Etch install: The OpenBSD drive is noisy, which probably means it's gonna go. The drive on which I installed Etch is much quieter. I probably need to get some newer, bigger drives ... or a whole new test box, but that's another story for another time.

Quirks in Debian Etch with openssh-server: I can run X apps, no problem. When I run:

$ nautilus &

... I get a huge window with the entire GNOME desktop, minus the toolbars. And I can't close that window -- Xming won't let me, I think. X-ing it out doesn't work. I had to kill the process in my PuTTY terminal. (Note: $ startx & does not work ...)

Speaking of security: OpenBSD is known for its security above all else. Here's how using openssl openssh (which was created by the OpenBSD team) differs -- at my lowly level, anyway -- between OpenBSD and Debian Etch:

In OpenBSD: The sshd server is included in the standard install. But it can't be used until rootly powers are used to implement it. Running X over ssh is not allowed until the appropriate configuration changes are made. But root logins are allowed over ssh by default; the administrator, however, can choose to block root login (which I did).

In Debian: Debian installs without the ssh server installed. So without the administrator specifically installing openssh-server, nobody can ssh into the box. But once that package is installed, Debian automatically allows ssh logins -- and X logins as well. As with OpenBSD in its default state, root logins are permitted over ssh until that feature is turned off in /etc/sshd_config.

I don't understand all the lines in sshd_config, but I probably should get better acquainted with each and every one of them.

Speed? It could be the fact that this Debian Etch box has the GNOME desktop, and I've been running OpenBSD either from the console or the default Fvwm window manager, but everything happens a lot faster with the OpenBSD install (hardware is the same for both). I could modify Debian to boot to a console instead of GDM, and that might speed it up a bit (memory is 256 MB), but whatever the reason, thus far OpenBSD is a bit smoother. (Later, things seemed to run a bit better when I didn't log in on the Debian box and hence didn't have GNOME running).

More on security: If this box wasn't just something for me to play with on the local network, the stakes would be a lot higher. I suppose not having sshd is pretty good security when compared to having sshd installed but not enabled. And I also suppose that installing sshd (openssh-server) means that you want to actually use it. But in the case of both OpenBSD and Debian, I wonder why root logins over SSH are enabled by default. If anything, I'd expect OpenBSD to disallow them until the administrator of the box decides to turn that feature on.

And since you can always use su or sudo (Ubuntu has conditioned me to like sudo, and I always add myself to the sudoers list with visudo, there's really no reason for a root login over ssh.

Side note: Debian doesn't automatically add the primary user to the sudoers list, something I always do because on many occasions I'd rather use sudo than su.

Ubuntu, by default, disables root logins entirely and only offers sudo. It makes setting root's crontab a pain in the ass. I use sudo -i crontab -e to get into root's crontab in Ubuntu.

Side note to a side note: While I can fake my way around vi, I like it when nano is the default editor and crontab -e brings up nano instead of vi. The one thing I don't like about nano is that when you wrap text, actually linefeeds are inserted. At least in vi you can have the text break in the middle of a word without turning word wrap on (although you are able to do so if you want wrapped text). The one thing I like in X editors is the ability for text to look wrapped without actually being wrapped.