Skip to content

autossh & expect

Hah! Don't try this at home work, kids:
$ cat otp.txt 
123456
234567
345678

$ cat autossh.exp
#!/usr/bin/expect -f
set ipaddress [lindex $argv 0]
set password [lindex $argv 1]
set command [lindex $argv 2]
set timeout 30
spawn ssh -L 1234:localhost:80 -N $ipaddress
expect {
        "yes/no"    { send "yes\r"; exp_continue }
        "password:" { send "$password\r" }
}
expect ""
# send "$command \r"
# send "exit\r"
 
expect eof
exit

$ cat otp.txt | while read p; do ./autossh.exp bob@ssh.example.com $p; done
Yes, public key authentication would be the way to go. But when used in combination with a (known) one-time password list, the above does the trick. No, I'm not actually using this and neither should you!

Fedora 15

Ready for yet another rant? If not, please skip this one. Fedora 15 has been released in late May 2011 so I upgraded my Alpha installation, let's see what we've got:
  • Sound does work now on this MacBookPro, if the speakers are unmuted:
    $ grep amixer /etc/rc.local 
    /usr/bin/amixer -c 0 set 'Surround Speaker' 115 unmute
    /usr/bin/amixer -c 0 set 'Front Speaker' 115 unmute
    /usr/bin/amixer -c 0 set 'Surround Speaker Playback Volum' 115 unmute
    

  • abrt is still unusable - how are people supposed to report bugs when the bugreporting tool is not working?

  • Since Empathy won't support OTR, trying to install Pidgin seemed the logical alternative. Not so on Fedora 15:
    $ yum install pidgin-otr
    ---> Package pidgin-otr.x86_64 0:3.2.0-4.fc15 will be installed
    --> Processing Dependency: pidgin >= 2.0.0 for package: pidgin-otr-3.2.0-4.fc15.x86_64
    --> Processing Dependency: libotr >= 3.2.0 for package: pidgin-otr-3.2.0-4.fc15.x86_64
    --> Processing Dependency: libotr.so.2()(64bit) for package: 
                                      pidgin-otr-3.2.0-4.fc15.x86_64
    --> Running transaction check
    ---> Package libotr.x86_64 0:3.2.0-6.fc15 will be installed
    ---> Package pidgin.x86_64 0:2.7.11-2.fc15 will be installed
    --> Processing Dependency: libpurple(x86-64) = 2.7.11-2.fc15 for package:
                                      pidgin-2.7.11-2.fc15.x86_64
    --> Finished Dependency Resolution
    Error: Package: pidgin-2.7.11-2.fc15.x86_64 (fedora)
               Requires: libpurple(x86-64) = 2.7.11-2.fc15
               Installed: libpurple-2.8.0-1.fc15.x86_64 (@updates-testing)
                   libpurple(x86-64) = 2.8.0-1.fc15
               Available: libpurple-2.7.11-2.fc15.x86_64 (fedora)
                   libpurple(x86-64) = 2.7.11-2.fc15
     You could try using --skip-broken to work around the problem
     You could try running: rpm -Va --nofiles --nodigest
    
    (Bugreport pending)

  • gvfs is killing me. It needlessly consumes resouces (also: try running du -sh * in your home directory when you accidently browsed some larger SMB share) and one cannot really remove it w/o removing all the depending packages too. I was able to remove gvfs-smb and gvfs-gphoto2, let's see if this helps.

  • Talking about resources, this is on a freshly installed Fedora 15:
    $ mount | awk '{print $5}' | sort | uniq -c | sort -n
          1 binfmt_misc
          1 debugfs
          1 devpts
          1 devtmpfs
          1 fusectl
          1 hugetlbfs
          1 mqueue
          1 proc
          1 rpc_pipefs
          1 securityfs
          1 selinuxfs
          1 sysfs
          1 vfat
          3 ext4
          5 autofs
          7 tmpfs
         11 cgroup
    
    Yes, that's eleven cgroup filesystems! And with all the other devices mounted all over the place (/dev/sda4 mounted in 3 different places? debugfs, what for? hugetlbfs, on a desktop machine - really?) the output of mount(8) just isn't useful any more.

  • Another thing: wasn't there a 20SecondStartup project? Oh, it's 100% completed? Hm, my system must be too slow then, it takes over a minute until the login screen appears. Pressing ESC during startup reveals a lot of daemons starting up. Let's help ourselves:
    for i in cups dnsmasq ebtables fcoe iscsi iscsid livesys livesys-late lldpad \
                lvm2-monitor mdmonitor sandbox; do echo $i && chkconfig "$i" off
    done
    

  • Oh, we're such a professional distribution - let's not allow our users to be insulted.

  • Ever since YUM had been introduced, I found it very slow compared to RPM or APT. And even today, it still is:
    $ time apt-cache search . | wc -l
    28031
    
    real    0m1.548s
    user    0m0.892s
    sys     0m0.124s
    
    $ time yum --cacheonly --debuglevel 3 list available | grep time:
    Config time: 0.210
    pkgsack time: 1.460
    rpmdb time: 0.000
    
    real    0m22.277s
    user    0m17.956s
    sys     0m2.957s
    
    Note: there are 28031 packages on this Debian/5.0 machine (PowerPC G4) and 23929 packages on that Fedora 15 (MacBookPro) machine - and yum(8), even w/o updating its caches is still ~20 times slower. Other operations are also much slower and bring the system to its knees. Upgrading from Fedora 15 -alpha to -final while watching a movie? Good luck... It's pathetic watching this system thrashing while yum is "working" :-\

  • That's it for now. Missing bug reports are pending, stay tuned.

    Why do I still put up with Fedora then? I'm still in need of a desktop operating system for this MacBookPro (which is an unfriendly beast to open source software, considering their hardware choices). And Fedora felt like the most mature desktop OS once, but maybe this has changed somehow....

The specified service has been marked for deletion

While trying to install eventlog-to-syslog on WindowsXP, one has to register evtsys.exe as a service ("Eventlog to Syslog"). Playing around with that a bit, this happened when trying to uninstall the service:
> sc stop evtsys
> sc delete evtsys
The specified service has been marked for deletion.
Why yes indeed, it had been marked for deletion - but the services.msc window was still open and the service could not be uninstalled properly the first time (sigh....). Closing the services.msc window might help; sometimes removing all the leftovers in the registry does the trick. But sometimes only a reboot will resolve this - as usual :-\