SSH Key Conversions: ssh-keygen (OpenSSH)

Tags

key conversion, openssh, ssh, ssh-keygen, ssh2

I’ve discussed this before, but this time I’m focusing on another angle. When interacting with commercial SSH implementations (such as exists on OpenVMS and Tru64 implementations) it becomes useful to know how to convert your OpenSSH public keys to SSH2 format and vice versa.

These examples will assume that you are using OpenSSH and are on a UNIX system. Note that these are public keys, not private keys. All key types (DSA, RSA) should convert fine, but DSA is the stronger cryptographic algorithm.

One you have a public key in the appropriate format, you can add it to the authorized keys file (whatever that may be called). This is normally found in ~/.ssh or ~/.ssh2 depending on the SSH version.

The OpenSSH utility ssh-keygen is what makes this happen. This utility can do a lot more than just generate keys. It can be used to change passphrases of encrypted keys; convert keys; generate public keys from private OpenSSH keys; and read and write keys to smartcards.

Converting an SSH2 key to OpenSSH

To use an SSH2 public key in OpenSSH, it needs to be converted. Use the ssh-keygen utility in this manner:

ssh-keygen -e -f ~/.ssh/id_dsa_ssh2.pub > ~.ssh/id_dsa.pub

Converting an OpenSSH key to SSH2

Using an OpenSSH public key in SSH2 requires a conversion; ssh-keygen can do this:

ssh-keygen -i -f ~/.ssh/id_dsa.pub > ~/.ssh/id_dsa_ssh2.pub

Advertisements

5 Ways to Increase Desktop Usability (and Productivity)

Tags

desktops, mutiple desktops, terminal, virtual desktops

Usability is the study of how you interact with your computer – and how to make the computer work easily and simply, the way you want it to. You can increase the usability of your own desktop yourself, even without modifying code or otherwise feeling “stuck” with what the software designers give you.

Here are some simple ways to increase usability (and thus productivity!):

1. Color terminal windows. This was mentioned yesterday, but it bears repeating for a general reason: with different color backgrounds, you can see at an instant which window you are on and where the window is that you want.
2. Cascade windows that go together. For example, when using multiple screen sessions, if you cascade them – that is, overlap them so that the top and left sides are visible – then it becomes easy to pick one at random. The windows can then be large as possible but still reachable at an instant. For best usability, make sure that there is a good amount of window visible when it is fully covered by other windows (I figure about 1 inch – 2.54 cm). This makes it possible to hit the window with the mouse very easily, and acknowledges Fitts’s Law.
3. Maximize windows when possible. This helps you focus on the current topic, and allows you to make use of the “infinitely large” window edges. If you are using Synergy, make sure to turn on the “lock to current screen” capability to make best use of this.
4. Use full screen viewing when possible. This is most often relevant to browsers (use F11) but is also true for PDF readers and terminal sessions. Unfortunately, most readers will default to “full page” viewing in full screen mode; some won’t let you change it. As far as terminal sessions go, if you are using only one, it will be most useful in full screen mode.
5. Use multiple desktops. This will allow you to move irrelevant windows outside your focus, and will permit you to switch to them with ease. For Windows, I use Dexpot; Linux comes with pagers built into KDE and Gnome and probably everything else. Dexpot has a very interesting feature that you can use to further increase usability: you can hide windows you almost never use to the system tray.

If you do these things, you’ll find that your productivity will go up and errors will go down – and your time with the computer will be much more stress-free.

Use Terminal Colors to Prevent Errors

Tags

color, rgb.txt, rxvt, x11, xterm

As administrators, we often are working on more than one system at a time. If you use screen as much as I do, you may find that all screens are indistinguishable from one another. This becomes a perfect place to separate the different systems into one or more xterms with different colors. You could try to use GNU screen colors (by adjusting the termcap and terminfo entries) but using xterm’s color set is easier.

Using multiple xterms (or rxvt terminals) you can color them in different ways to represent different systems. With different xterm windows, you can also separate the windows in space by putting them in different areas of the screen.

You can also set the backspace key when you start up an rxvt session. Use the –backspacekey option with the appropriate string (such as “^H”). Combined with the background and foreground colors, you could start rxvt with a command like:

rxvt -bg LemonChiffon -fg Black --backspacekey "^H"

The names of the colors can be seen in the file rgb.txt included with X11; in Red Hat Enterprise Linux, it can be found in /usr/share/X11/rgb.txt. For some reason, Ubuntu doesn’t have this file; it seems to be expected by many programs in either /etc/X11/rgb.txt or the previously mentioned /usr/share/X11/rgb.txt. For some strange reason, the folks at Ubuntu refuse to load it into the base; here is a bug report that showcases some of the back and forth on the topic. You can download the current rgb.txt and put it into the correct path if you have to.

My favorite colors for backgrounds – easy on the eyes, easy to read black text – are these:

• LemonChiffon
• SkyBlue
• PowerBlue
• IndianRed
• Plum1
• PaleTurquoise

There are complete lists of X11 colors on the web, such as this page or this page – or this sortable table of colors.

You can also see the colors through the use of the programs xcolors and xcolorsel, both of which do similar things. Both are available as packages for Ubuntu and both require rgb.txt which is probably missing. There don’t seem to be RPM packages for Red Hat Linux (and variants) xcolors or xcolorsel for some reason, although both OpenSUSE and Mandriva look like there should be some current packages for these programs.

Multiple Screens: A Usability Nightmare?

Tags

fitts law, multiple monitors, synergy

I’m surprised I haven’t seen anything about this anywhere else. When multiple screens are connected together, you lose one (or two) of the most important features of a single window: the right and left edges. As Bruce Tognazzini mentions in his timeless article on Fitts’ Law, the edges are very fast for user access. This is one reason that Apple’s menu bar (across the top) is so much better than the way Sun and Microsoft and others have done it: see point 5 in Tog’s article.

There is also an absolutely wonderful writeup of Fitt’s Law by Kevin Hale titled Visualizing Fitts’ Law – with a presentation with excellent visualizations and examples. Jensen Harris also wrote an article on Fitts’ Law: of particular note are the examples of how Fitts’ Law affected the design of Microsoft Windows and Microsoft Office.

In Tog’s article on Fitts’ Law, he describes how he experimented with “multiple desktops” (though at the time, it may have seemed more arbitrary than that). With a second monitor on top of the first, and a menu that users could “bypass” into the top monitor, it actually slowed the user down quite considerably: at first, the menu was missed quite often until the user slowed way down to get at the menu.

When using multiple monitors in a horizontal direction (a typical layout) the right edge of the left screen and the left edge of the right screen become very hard to hit. This especially becomes a problem with programs that are maximized. Consider the example of a typical scrollbar (normally on the right hand side) on a maximized application on one of the two monitors. On the left-side monitor, it becomes a hard target as the user has to directly aim and slow down to hit it. If on the right-side monitor, the scroll bar essentially becomes infinitely large and can be hit without any trouble at all.

Using multiple monitors also completely eradicates two of the five easiest locations to reach: two corners are no longer easily “reachable” – or perhaps reachable at all. This easy reachability of the corner is perhaps one reason that programs put the window control buttons in the top right corner; with another monitor on the right the corner becomes that much harder to hit. If there is a monitor above, then it becomes just that much harder.

When using multiple monitors on on system tied together, the possibilities of rectifying this usability problem is only available to the extent that the operating system allows it. However, if you use synergy to tie multiple computer displays together, there is at least, several ways to regain the “infinitely large” target of a screen edge.

One is to use the “lockCursorToScreen” capability of Synergy. Synergy uses the ScrollLock key to do this by default. You can also use a hot key – this display is from the Synergy+ server for Windows:

Hot Key Configuration Window

Hot Keys are set at startup, accessable via the Hot Keys button. With a mouse and window “locked” with this option, you get back your right and left edges, and they once again behave the way operating system designers expected. With the toggle, you can go back and forth. There is, however, no way to discern whether the screen is locked or not, aside from the fact that the ScrollLock key setting is often visible on the keyboard: this is a usability failing in this feature.

Using the “double-tap” or “time delay” features of Synergy (with respect to switching displays) turns out to be extremely frustrating for the user, switching at times that are unexpected and not switching when desired.

Another possibility would be to not link the multiple displays together at all, and use key commands to switch between screens. This, however, may be more trouble than it is worth; I’ve not tried it and it does not seem possible to configure Synergy+ this way from the configuration screens.

The Benefits of Time Tracking

Tags

baralga, gnotime, ktimer, timetracking

Time tracking is an area where admins (and others) often have strong feelings – perhaps because one has been required to keep track of time for multiple different ways, having to enter similar data every day or every week – or perhaps because the time tracking was so detailed that one could easily spend more time tracking time than doing anything worthwhile. However, when we are recording time just for ourselves – perhaps we can resolve all of these problems ahead of time and use time tracking to its fullest potential.

Tracking your time can be of benefit, especially if you are self-employed. Even if you are not “self-employed”, to some extent we all are self-employed: you provide a service to your employer and your continued employment hinges on the value you bring to the employer. Even if you are looking for work: your job is to provide quality job searching prospects to yourself. Tracking your time can show you where the time went – and how much of it was really useful. If you are focusing on one area and the more important projects are sliding behind, then tracking will show this.

Remember: this tracking is only for you; so no fudging and no fear of what others will think – be honest in your tracking.

Tracking time does not have to be a minute by minute process (albeit some employers may make you do this, at least down to the five minute level). Tracking may be best done on a 15 minute basis; nor do you have to give up if you forget to record one start time – most applications should allow you to track your time retroactively (don’t abuse this capability!).

Time-tracking applications is one of those areas where there are a hundred different applications with different features. For whatever reason, no open source variant is a hands-down winner in this area; if you investigate you will find numerous versions of “time tracking” software, some of which are quite simple and some of which are very complex and all-encompassing.

For the purpose I am describing, a simple system is best. I recommend for Linux one of KTimer (included with KDE), GnoTime, or Project Hamster (now included with Gnome). For Windows, there is Baralga – which is also platform independent as it is Java-based. All of these are perfect for personal time tracking.

Many time tracking applications are designed for massive projects, for teams, or to provide everything to everybody. Programs such as those mentioned will provide the basic time tracking without all of the other things that get in the way – permitting you to boost your productivity every day.

Building a Checklist

Tags

checklists, notes, planning

When you are undertaking an invasive and complicated process, you should have a checklist to go by. This will help you make sure you cover all the bases and don’t forget anything. I’ve written about this before.

However, how do you build a checklist that will be of the most assistance?

First, “build” is the right term: in the days or weeks leading up to your process (system maintenance, for example), come back to the checklist over and over. Review it several days in a row, or better yet, several times a day. You’ll think of new things to add to it, and you’ll be fleshing it out until it is comprehensive and complete. You might want to leave it loaded in your workstation so you can come back to it whenever the mood strikes.

Secondly, break the checklist down into major sections. For example, in patching a system you might have sections for: 1) preparing the system; 2) patching the system; 3) rebooting the system. Other processes will have different major sections. These major sections should be set apart on your checklist, preferably with titles and bars that segregate the checklist into its component parts. I recommend a different color background and a large bold font to set it apart.

Thirdly, there should be a “point of no return” – which should be at a major section break. This is the point where you cannot turn back and return to the way things were. At this point during the process, you have to choose: have things gone smoothly enough that completion is likely – even inevitable – or is the process in such disorder and disarray that a return to the status quo would be better? At that point, one must choose.

With such a checklist, your process will be much smoother, and you won’t have to explain to the boss why you missed something critical. It’ll also document what you did (along with the notes you take).

The Dichotomy of a System Administration Career

Tags

jobs, specialization

When you choose to work in system administration, generally you have to focus on one operating system or another. The dichotomy comes in choosing a system to focus on for your career.

How do you go about choosing which system you want to administrate as a career? Do you go with a common system like Microsoft Windows or a relative rarity such as OpenVMS?

If you go with Microsoft Windows Server, for example, there will always be jobs available (relatively so, anyway). Every corporation seems to have at least one Microsoft Windows Server, and they all need to be taken care of by someone who knows what to do. However, there will be lots of other people that do the same thing. So even as there are jobs out there, there are lots of applicants and lots of competition. With this abundance of people who know how to administrate Windows servers (or think they do) comes a lower pay, as an employer can be selective in who they choose. This is the basic economic principle of supply and demand at work.

On the other side is administering UNIX servers – or even more so, OpenVMS servers. The number of people who can administrate these servers is less than those who work with Windows, which means their expertise is more expensive. For a variety of reasons, UNIX is present less in the average enterprise, and the number of UNIX servers is very likely dwarfed by the number of Windows servers. This is an advantage as the pay scale will be higher, but the disadvantage is that the jobs will be fewer.

When the market is tight, those with more specialized skills will find themselves having to move where the work is, and will have to search further afield for possible openings. It is a trade-off – and it’s your choice. Just be sure you have the facts first before you choose.

Expanding OpenVMS Memory

Tags

AUTOGEN, BALSETCNT, GBLPAGES, GBLPAGFIL, MAXPROCESSCNT, memory, MODPARAMS.DAT, VCC_CACHE_MAX

When you expand OpenVMS memory, there are a number of other parameters you may wish to revisit. If you increase your memory dramatically, you will certainly have to change these SYSGEN parameters. You can also look each parameter up using HELP:

HELP SYS VMS_MAX_CACHE

(The parameter SYS is short for SYS_PARAMETERS.)

Some parameters to consider changing are the following:

• GBLPAGES. If you don’t increase this, you’ll be getting warning messages when you try to take advantage of all that memory. In short, this parameter sets the amount of memory that the kernel can keep track of; if you use too much this parameter is a limiting factor.
• GBLPAGFIL. The page file needs to be able to take all of the pages that it might be called upon to reserve; increase this parameter.
• VCC_CACHE_MAX. If you’ve not tuned your cache (XFC) then you’ll find half of your memory to be taken by the cache. This is almost certainly not what you want; modify this parameter to reduce the amount of memory your cache is allowed to take. Even so, do remember that your cache will decrease and increase dynamically in any case – but if you scale it back, then you’re not wasting memory so much.
• MAXPROCESSCNT. This sets the maximum number of process slots – in essence, the maximum process count (which is what the parameter is called, after all). If you have a lot more memory, you’ll want to use it to run more, right? That’s not any good if you use too many processes and can’t run any more.
• BALSETCNT. If you set MAXPROCESSCNT, you should set BALSETCNT to the same amount minus two – and never higher.

These changes can be made in the SYS$SYSTEM:MODPARAMS.DAT file and then use the AUTOGEN command to configure the sysetm. The MODPARAMS.DAT file uses a simple format; for our purposes, you can use something like this:

ADD_GBLPAGES=1000
ADD_GBLPAGFIL=1000
VCC_CACHE_MAX=2048
ADD_MAXPROCESSCNT=1024
ADD_BALSETCNT=1024

In place of ADD_* you can also use MAX_* or MIN_*. You can see more examples in HELP AUTOGEN MODPARAMS.DAT. AUTOGEN is described in the HELP; be careful using it! You don’t want to muck up the system so bad you have to reboot or to reinstall.

Powered by ScribeFire.

User Interface Design: the Command Line

Tags

arch, bazaar, git, remnant, revision control, user interface design

The command line is not immune from user interface design. Especially with the concept of language, one has to choose carefully the options and names and orders of the things in order to make things work just the way the user expects them to.

If the program is too different, people will be tripping over it all the time. The UNIX tar command comes to mind as one that failed here: options (or “actions”) specifically did not start with a dash. Likewise, UNIX find also failed: if you didn’t include the parameter -print at the end, you saw no output: your find command found nothing! (In reality, it just didn’t report it.) Both of these errors have been rectified in the last several decades: UNIX find has an implied -print, and tar often will make the dash optional – which makes it work both the way it always did and the way it should have.

As an example of what seems to be a colossal user interface failure – including poor writing – consider these articles from Scott Remnant which are absolutely a gem (albeit from way back in February 2009). He wrote an article titled Git Sucks – which was then followed by a second and then a third – followed by yet another titled Revision Control Systems Suck.

What Scott is railing about is how hard these systems are to learn (he targets not just git, but also GNU Arch and Bazaar). From his standpoint, he finds these systems to be complicated and hard to understand.

He also points out (rightly) that the most common actions should be the simplest, and finds that with git these common actions are rarely ever simple. He specifically mentions reviewing the changes that someone else has made compared to his own – and says that there’s not a revision control system that makes it easy.

An example of how user interface design can be incorporated into things like the command line and even programming is this quote from an interview with Yukihiro Matsumoto, the developer of the programming language Ruby about his guiding principle in developing Ruby:

[It’s] called the “principle of least surprise.” I believe people want to express themselves when they program. They don’t want to fight with the language. Programming languages must feel natural to programmers.

and later in the same interview:

In addition, Ruby is designed to be human-oriented. It reduces the burden of programming. It tries to push jobs back to machines. You can accomplish more tasks with less work, in smaller yet readable code.

Another example: I was just rereading my copy of The Humane Interface written by Jef Raskin. In it, he had a section titled Noun-Verb versus Verb-Noun Constructions (section 3-3, p. 59). This mirrors a problem I have experienced with some command line software in the past: the command wants an action as the first argument, and the object of the action second. I despised it enough that it was the genesis of my writing a wrapper for the command that reversed the order: object first, action second. Imagine my surprise to find my troubles validated right there in Raskin’s book.

There are many examples of command line programs doing wrong things, and of programs doing right things. One of the right things comes from HP-UX and its software management tools such as swinstall: if the program can use an X display for a graphical display, it will: but if not, it goes to a text display instead.

There are many such examples, of programs just doing what you need and leaving you to think about other things. I wonder what would happen if a company like Apple decided to tackle the command line – although, in a way, they did already. In MacOS X, consider the open command for instance… absolutely brilliant, which is in contrast to the open command sometimes found in other UNIXes (never standard).

One very important point to remember: “It’s only hard until you learn it” is not a valid excuse. The learning curve for a program should not be any steeper than it has to be.

Renaming a host (UNIX, OpenVMS)

Tags

hostname, renaming host

Renaming a host is not, in general, a pleasant experience. The general requirement is that you must find everywhere that your hostname is specified and change it.

In OpenVMS, this can be an extensive process, and even require relicensing if you have licenses that depend on your hostname. It can also require rebooting of an entire VMS cluster if you miss changing a parameter. The full details are in the VMS FAQ such as this one (dated from 2001) from faqs.org or this one from HP (undated). Hoffman Labs has a copy from September 2006; there is information on changing a node name in section 5.7.

Not that in changing the OpenVMS hostname in a cluster, you must change the SCSNODE parameter (which changes the cluster node’s nodename). If you change the SCSNODE parameter, you must change the SCSSYSTEMID as well or the entire cluster will refuse to function until it is reconfigured. The cluster tracks the pairing between these two parameters, and if the pair changes, then the cluster stops working normally.

For UNIX in general, one way to do it is to go to the /etc directory as root and run a search:

$ su -
Password:
# cd /etc
# find . -type f -print | xargs grep -i myhost

After running this, change all of the instances of myhost that is found.

This is the way to change hostnames in Solaris, including Solaris 9 and Solaris 10. Debian and derivatives (including Ubuntu and Linux Mint) and HP-UX make it simpler.

In Debian, there is a file called /etc/hostname. This will contain the current setting of the hostname. Change this to your desired new hostname, then run the shell script /etc/init.d/hostname.sh.

In HP-UX, change to root and run the program set_parms with the hostname option:

# set_parms hostname

For all of these possibilities, the best thing to do is to reboot afterwards: this will test the new setup as well as change any in-memory hostname settings.

Changing a hostname is a drastic measure, and will include much in the way of system modification and updates. Changing the actual hostname is very likely only the beginning; there may be clients that are set up to contact the host, and any services that the server provided (e.g., NTP server, FTP server, web server, NIS server, etc.) will require reconfiguration on the clients to use the new hostname.

In summary, the very best thing to do is to get the name right in the first place.

Powered by ScribeFire.