Northward Midget

Tag: sysadmin

  • Why 80 characters?

    Searching for reasonable values for the *.vt100.geometry[5-6] xterm menu font-menu options in my ~/.Xdefaults file, I re-stumbled a gem of computing history as the top-answer to a question on StackOverflow, and this pretty picture of an old IBM punch-card.

    Inspired by a perl script within the comments, I ran this shell pipe:

    2015-07-23 10:30:00 :: ~
 rons@rons-VM$ find /usr/share/terminfo/ -type f -printf '%f\n' |
   xargs -n1 infocmp | egrep -o 'cols#[0-9]+, *lines#[0-9]+' |
   sort | uniq -c | sort -nr | head
 489  cols#80,  lines#24
 58   cols#132, lines#24
 55   cols#80,  lines#25
 27   cols#80,  lines#34
 15   cols#80,  lines#40
 15   cols#80,  lines#31
 14   cols#80,  lines#33
 12   cols#126, lines#24
 10   cols#85,  lines#64
 8    cols#80,  lines#42

    Unsure if infocmp normalizes its output such that the cols and lines entries will always be adjoined, but this is good enough for my purposes.

    80×24 wins by a landslide, with 132×24 a distant second.   Then I found a Gnome help page which added 80×43 and 132×43 as options for its gooey{sic} terminal.  Next, a quick stop at the SVGA documentation in the Linux kernel with another list of common geometries.

    Finally, the Wikipedia Text Mode entry which included a neat table of common text modes:

    Text res. Char. size Graphics res. Colors Adapters
    80×25 9×14 720×350 B&W MDA, Hercules
    40×25 8×8 320×200 16 CGA, EGA
    80×25 8×8 640×200 16 CGA, EGA
    80×25 8×14 640×350 16 EGA
    80×43 8×8 640×350 16 EGA
    80×25 9×16 720×400 16 VGA
    80×30 8×16 640×480 16 VGA
    80×50 9×8 720×400 16 VGA
    80×60 16 VESA-compatible SVGA
    132×25 16 VESA-compatible SVGA
    132×43 16 VESA-compatible SVGA
    132×50 16 VESA-compatible SVGA
    132×60 16 VESA-compatible SVGA

    I think I’ll go with 80×50 and 132×60.

     

  • ssh: no matching cipher found

    After a recent Ubuntu upgrade on my home machine, ssh attempts to it from the VirtualBox instance at work stopped working.   Here’s what ssh spewed back at me:

      no matching cipher found: client blowfish-cbc,arcfour server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

     

    Impatient, I just logged in from another machine.  The VM runs CentOS 5.10 so that its environment is comparable with what [used to be] present on the majority of our production servers.   I’m an anti-RedHat bigot in the first place, and didn’t want to hunt down repos and upgrade my ssh.

    That was not necessary.  The problem was a “Ciphers” line I’d added to my ~/.ssh/config, intended to prefer  (“Googallegedly”) faster encryption methods.   Adding all but those that resemble email addresses seems to have fixed the issue.   My “Ciphers” line now looks like this:

      Host *
  Ciphers blowfish-cbc,arcfour,aes128-ctr,aes192-ctr,aes256-ctr

     

    The ciphers may be defined in your system /etc/ssh/ssh_config.  Check around.  If you can’t find it anywhere, try this:

      sudo find  ~/.[a-z]* /etc -path '*ssh*' -type f | sudo xargs fgrep Cipher

     

    Anyway, that was my fix.   Right on in, easy-peasy lemon-squeezy.

     

  • Mounting Windows Shares On Linux

    There must be a gazillion posts on this, so I’m just going to concentrate on what I did wrong.

    First I wanted to mount the target share as NFS, but the server doesn’t export to our desktop subnet at work. I saw it was running Samba, and remembered having had it working on Windows XP, so tried that. A friend at work had an /etc/fstab line that almost worked.

    Turns out smbfs is deprecated and cifs is the new smbfs, so there was a documentation detour of sorts. Anyway, I contacted infrastructure and they gave me a line that worked, but included the password. My coworker’s line used a credentials file, and I’d prefer that, because I’m old-school anal about including passwords in the clear and logging in as root and that kind of thing.

    So, I took the infrastructure guy’s fstab line, turned it into a mount command, ran it with three verbose flags, and saw it was trying to log me in as root, even though my credentials file included my own username.

    The fix turned out to be to explicitly add another username option to the line:

    //samba-server/dude /ext/dev/dude cifs rw,credentials=/home/dude/.ntcred/dev,username=dude,uid=dude,gid=dude,auto,user 0 0

    Replace “dude” with your username everywhere. Here’s my ~/.ntcred/dev file:

    username=dude
password=dude-password
domain=dev

    Replace everything with the appropriate values.  I’m not sure the domain even matters in this case, but it’s the NT domain/workgroup of the share.

    I think the root of the problem is the parsing of credentials files.  Apparently extraneous whitespace causes it to b0rk itself up.

    Oh, and the “user” option (to allow any user to mount it, as opposed to just root, or the conflicting “user” option to samba) won’t work unless you set the cifs commands suid root:

    chmod +s /sbin/*mount.cifs

    Your package manager will probably gripe and/or change that back whenever an upgrade comes up, and since we’re using “auto” it’s going to be mounted on boot, anyway, so you might as well just sudo the mount the first time and then rest easy.

    While I was at it, I tried mounting a few other shares on another domain.  One works fine.  When I try to enter any subdirectories of the other, everything goes to hell.   So, whatever.  I’m done.