Drop By!

Say you want to record a video live stream from the internet for example from the Streaming CCC Congress in Berlin 2007.

This can be accomplished using the glorious mplayer HOWTO Rip Streams With MPlayer.

To stop the recording after a certain amount of time use this simple script (see also my post Finding Child Process Pids … ):

#!/bin/bash
URL=$1
FILE=$2
# duration in minutes
DURATION=$3
mplayer -framedrop -autosync 30 -cache 10000 -dumpstream $URL -dumpfile $FILE &
sleep $DURATIONm
kill %+

Now you need to start this script at a certain time. For that you could use the linux “at” command (see at). To run it you have to export the DISPLAY variable on ubuntu (see Bug #94933):
export DISPLAY=$DISPLAY ; export TERM=$TERM; echo "echo 'Hallo'" | at  now

But I prefer KAlarm from KDE to schedule tasks which should run only once.
Run KAlarm, create New Alarm, choose Action “Command”, enter the path to your script with appropriate arguments for stream url, dumpfile and duration in minutes:
/home/myhome/scripts/stream_ripper.sh mms://streaming-internet.fem.tu-ilmenau.de/saal3 test.asf 60
, adjust all other settings which are quite self explaining. Use the template feature of KAlarm for similiar tasks.

To control background child processes from a shell script you want to know the PID or job-id of the child. Here are some ways to do this:

First starting a background process echoes the job-id and pid of the process:

$ emacs &
[1] 15393

The PID of the last command set to run in the background by the current shell or script is stored in $! variable:

$ echo $!
15393

This you could find out by using the jobs command:
$ PID=`jobs -l | sed -n 's/^\[[0-9]*\] *+  *\([0-9]*\) .*$/\1/p'`; echo $PID
using the fact that the last current (last started) job will be marked by a + in
jobs -l output.
To terminate the current job you don’t need the explicit job-id:
$ kill %+
The exit status will be stored in the $? variable.
Read more in the Advanced Bash-Scripting Guide:Job Control Commands

To see your currently used user directory go to Help – About – Details.

To override the default settings in the file netbeans-install-dir/etc/netbeans.conf you can create a directory etc/ in /home/myhome/.netbeans/6.0 ( with 6.0 being the version number of your NetBeans installation). Then use the default netbeans.conf file from netbeans-install-dir/etc/netbeans.conf as a template to create a user specific settings in /home/myhome/.netbeans/6.0/etc/netbeans.conf (see How do I make my custom startup parameters permanent? ).

For instance you could change you user name (used in templates):

# Options used by NetBeans launcher by default, can be overridden by explicit
# command line switches:
netbeans_default_options="-J-client -J-Xss2m -J-Xms256m -J-XX:PermSize=64m -J-XX:MaxPermSize=200m -J-Xverify:none -J-Duser.name='My Name' -J-Dapple.laf.useScreenMenuBar=true -J-Dswing.aatext=true --fontsize 14"

(… or use Tools -> Template Manager -> User configuration properties .)

Read more about startup parameter for Netbeans IDE in FaqStartupParameters .

It seems there are basically two ways to set the correct author name (opposed to the system user name Eclipse is using per default) in Eclipse as it appears for example within the autogenerated javadoc comments.

First using -vmargs settings:
eclipse -clean -showlocation  -vmargs -Xms512m -Xmx900m  -XX:PermSize=128m  -XX:MaxPermSize=128m -Duser.name="Your full name"

The other one is just by  changing the associated templates in Window -> Preferences -> Java -> Editor -> Templates -> @author , hardcoding the author’s name.

I already wrote how to configure the ssh-client for single-sign-on in Convenient SSH on Linux. Today I would like to jump up to the KDE-Layer and see what there can be done to organize networking more effectively. Formerly I used kssh to organize my ssh-accounts (see Installing kssh on ubuntu). Nowadays I prefer a combination of KDE’s Network Folders and Terminal Sessions.

KDE Network Folders can help you to organize your remote access links. It is based on KDE’s support of webdav, ftp, sftp, smb and fish. Fish is quite interesting, it presents files over ssh just as they would be local. There is a special directory where your network folders are stored – type "remote:/" into Konqueror’s address bar. (Other possibility is of course to use simple bookmarks to organize remote connections accessed via “sftp://user@host/” or similiar.) It is just a collection of links which are stored in .kde/share/apps/remoteview by KDE.
The real value of Network Folders lies in the combination with Network Folder Wizard which gives you a configuration interface and quick access list in KDE’s panel.
Read the documentation of knetattach in Konqueror "help:/knetattach/introduction.html" which is the application behind Network Folders administration, also known as Network Folder Wizard also available as an applet by "RightClick Panel" ->  "Add Applet to Panel" -> "Network Folders".

Teminal Sessions is an other applet you can add to your panel. It will list the different konsole sessions. I use sessions to configure ssh shell access and to execute common shell commands like watching remote logs etc. . To add a session open a konsole window, in the menubar click "Settings" -> "Configure Konsole" -> "Session"-tab . In the “General” group type a name for your session, the command to execute (example: ssh xxx.gebewau.de) and your working directory, click save session. You can associate different color schema and icons with different sessions to have better orientation between konsole windows for different purposes. There seems to be no grouping feature for session links.

The Problem: There are a bunch of servers I need to login almost daily using ssh, all with different login names and passwords. I also want to secure copy data between them and access one server from another.

The Wish: One password for a group of servers to type in only once when I login into the local X-session.

A Solution: Set up passphrase protected private and public keys. Make ssh-agent run your window manager und type the keys passphrases into a pass-phrase dialog triggered by ssh-add on window managers startup. Use the ssh-agents forwarding features to forward local ssh-identities between remote hosts. Of course you
also need to configure your public key on the remote hosts.

So it goes:

1. Install x11-ssh-askpass (ubuntu package ssh-askpass).
2. Create key pairs and protect them by a (hopefully) strong passphrase:
   

   ~/.ssh$ mkdir mykeys
   ~/.ssh$ cd mykeys
   ~/.ssh/mykeys$ ssh-keygen -t dsa
   Generating public/private dsa key pair.
   Enter file in which to save the key (/home/me/.ssh/id_dsa): /home/me/.ssh/mykeys/gebewau_dsa
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/me/.ssh/mykeys/gebewau_dsa.
   Your public key has been saved in /home/me/.ssh/mykeys/gebewau_dsa.pub.
   The key fingerprint is:
   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   ~/.ssh/mykeys$ chmod 600 *

   
   To use the keys it is necessary to set strict permission on the files, otherwise ssh won’t accept them.
3. Edit your .xinitrc (on ubuntu ssh-agent is running by default, see post SSH on Ubuntu , SHH-Agent Is Running per Default), add this line:
   

   #!/bin/bash
   exec ssh-agent sh -c '{ for f in /home/kostja/.ssh/mykeys/*_dsa ; do ssh-add $f  </dev/null ; done ; } &&  exec startkde'

   This will start ssh-agent once to use in all sessions. ssh-agent will start a shell (bash in my case) which in turn executes the command enclosed within ‘ ‘. Foreach private key in mykeys directory there will appear a passphrase dialog triggered by ssh-add . The passphrase dialog is provided by x11-ssh-askpass. For this ssh-add reads the SSH_ASKPASS environment variable (in ubuntu it seems not to be neseccary) which you can set in your ~/.bashrc file :

   # Set the location of the x11-ssh-askpass binary
   export SSH_ASKPASS=/usr/local/libexec/x11-ssh-askpass

   
   On success – startkde will be executed. To see how to run the session independently from the success of the passphrase dialog read the description in Simplifying SSH access using an agent
4. Configure your ssh client to use agent forwarding by creating and editing the configuration file .ssh/config. An example:
   

   # selfmade OpenSSH ssh client configuration file will
   # override the system config file in /etc/ssh/ssh_config
   #
   # Config options are unioned over all matching host
   # entries, first config option wins
   
   Host xxx.gebewau.de
   # with this user setting you only have to type
   # ssh xxx.gebewau.de to connect
   User me
   
   Host *.gebewau.de
   # don't need this if identity is added by ssh-add
   #  IdentityFile ~/.ssh/mykeys/gebewau_dsa
   # next two settings have security issues, see man:ssh_config
   ForwardAgent yes
   ForwardX11 yes
   
   Host *
   CheckHostIP yes
   Compression yes
   StrictHostKeyChecking ask
   SetupTimeOut 300
   ServerAliveInterval 300
   

5. Install your identity.pub in a remote machine’s authorized_keys. You can use scp to copy your public key file to the remote server followed by:
   cat gebewau_dsa.pub >> .ssh/authorized_keys
   Or you use
   ssh-copy-id -i ~/.ssh/mykeys/gebewau_dsa.pub user@xxx.gebewau.de
   this will also set the right permissions in the servers ~/.ssh directory.

To use AgentForwarding you have to use ssh -A or enable forwarding in .ssh/config for the local client and for the client on the bridge server. The bridge servers client will try to use your username you used to log into it. So the set appropriate user names in .ssh/config or use : ssh forwardeduser@over-the-bridge.gebewau.de .

Note about adding several matching identities with ssh-add:
If you have several identities which can access the same host then ssh will only use the first matching one added by ssh-add. Even using command line option -i won’t override it.
So if you have two SSH identities valid on an SSH server, you better don’t load either identity into an agent. Otherwise, one of those identities will be unable to access that server. You may also try to set the config option IdentitiesOnly in your clients config file.

Security remark regarding forwarding found in man:ssh_config:
Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent’s Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.

Links:

• OpenSSH key management, Part 3 – 3. Part of a good article, with a clear illustration of agent forwarding.
• Remote Access – well structured SSH overview
• Top Ten Secure Shell FAQs
• SSH Book
• ssh-agent/ssh-add question – useful post about configuring ssh-add/ssh-agent on X startup