Northward Midget Pole to Pole

23Jul/150

Why 80 characters?

Posted by Quinn

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.

80x24 wins by a landslide, with 132x24 a distant second.   Then I found a Gnome help page which added 80x43 and 132x43 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 80x50 and 132x60.

 

28Apr/150

ssh: no matching cipher found

Posted by Quinn

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.

 

Tagged as: , , No Comments
6Apr/110

Mounting Windows Shares On Linux

Posted by Quinn

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.