fortune bible

probably not to everyone's tastes, but may generate some ideas for others ;)

i grew weary of the random quotes, and wanted something more inspirational O:)

#! openbox background/wallpaper

i keep only openbox relevant stuff in the openbox/autostart, and moved everything .xsession. this way, i can seemlessly change wm.

my ~/.xsession contains:
hsetroot -solid "#000000" -fill ~/.wallpaper &
...
exec openbox-session

i have commented out wallpaper settings in ~/.config/openbox/autostart, like so:
## Set root window colour
#hsetroot -solid "#2E3436" &

## Group start:
## 1. nitrogen - restores wallpaper
## 2. compositor - start
## 3. sleep - give compositor time to start
## 4. tint2 panel
#nitrogen --restore && \
(\
cb-compositor --start && \
sleep 2s && \
tint2 \
) &

my problem:
hsetroot in ~/.xsession correctly sets my wallpaper. at some point during openbox startup, the wallpaper settings are reset, and i end up with a blank grey background at the end of openbox startup.

my question:
what/where is this happening?

---

thanks for the hint to look at openbox configs. i suspected something running from somewhere in my user configs. it is rather strange that openbox would contain hard-coded configs overwriting user settings. i would consider this a bug. would this be openbox upstream or crunchbang specific?

/usr/bin/openbox-session calls
1. /etc/xdg/openbox/environment
2. $HOME/.config/openbox/environment
3. /usr/lib/openbox/openbox-autostart

/usr/lib/openbox/openbox-autostart sets background, resetting any user settings for background/wallpaper. then it calls
1. /etc/xdg/openbox/autostart
2. $HOME/.config/openbox/autostart
3. /usr/lib/openbox/openbox-xdg-autostart

which means that any ~/.xsession settings, conflicting in any of the above files, would be overwritten. openbox expects all user x configs to be within openbox only, which i think is plain wrong.

i have commented out the background color section in /usr/lib/openbox/openbox-autostart, which resolves my op. thanks porkpiehat :)

/etc/X11/openbox/ is yet another directory with openbox configs

i am loathe to edit system configs, as they might conflict with upstream upgrades later when i might not remember what/why i changed something. hence why i keep them pristine, preferring to keep my settings in local user configs. this also help me seemlessly switch wm and/or carry them over to other machines.

would openbox expect users to call ~/.xsession at the end of ~/.config/openbox/autostart? that would be crazy logic :o

---

ref: http://crunchbang.org/forums/viewtopic.php?id=31614

debian time

check whether your system uses utc or localtime
$ cat /etc/adjtime

if utc, all is well. you might find hwclock set to localtime.

it is recommended to use utc for every os.

ssh keys

ssh keys can be configured to enhance security, with password-less logins. no password is typed or transmitted.

the basic steps are:
- generate your keys at local end
- secure your private key
- gather your public key
- add public key to remote end

we will look at my two preferred tools:
(1) putty
(2) dropbear

i don't seem to prefer openssh, the seemingly defacto standard, as i consider it bloatware. too big does obscure/obfuscate vulnerabilities. look at my preferred alternatives - so tiny, so beautiful :-)

---

putty-tools are rather quirky to get right the first time. but once you have them setup right, and understand what you are doing, you'll love 'em. i like them also because they are much smaller and efficient than openssh-client, the supposedly defacto standard. putty, though, is very much the defacto choice on windows.

generate your rsa key file on the ssh client
$ puttygen -t rsa -b 4096 -o puttygen_rsa

do not modify puttygen_rsa. copy the Public-Lines from the key file to another file, say puttygen_rsa.pub.

ensure all puttygen_rsa.pub is one word on one line, i.e. join all lines together, with no spaces in between.

now insert "ssh-rsa" and a space in front. you may optionally add your id at the end, ie a space and "ssh-user@ssh-client". there should be a space in between each of these three items. and this file still contains everything on one line only - your public key.

send your puttygen_rsa.pub to ssh servers
$ pscp -v ~/.ssh/puttygen_rsa.pub ssh-user@ssh-server:/home/ssh-user/.ssh/

at the ssh-server
$ cd .ssh
$ cat puttygen_rsa.pub >> authorized_keys

ssh config is now complete, and we can test it from the client.
$ plink -v -i .ssh/puttygen_rsa ssh-user@ssh-server
$ plink -v -X -i .ssh/puttygen_rsa ssh-user@ssh-server
$ pscp -v -i .ssh/puttygen_rsa source-files ssh-user@ssh-server:/destination-directory

---

dbclient is much simpler, generate your rsa key file on the ssh client
$ cd ~/.ssh
$ dropbearkey -t rsa -s 4096 -f dropbearkey_rsa

copy/paste the generated Public key portion to dropbearkey_rsa.pub and send it to the remote end.
$ scp -S dbclient dropbearkey_rsa.pub ssh-user@ssh-server:/home/ssh-user/.ssh/

at the remote end, add your public key to ~/.ssh/authorized_keys.
$ cd ~/.ssh
$ cat dropbearkey_rsa.pub >> authorized_keys

now you can ssh from your client
$ dbclient -i ~/.ssh/dropbearkey_rsa ssh-user@ssh-server
$ scp -S dbclient -i ~/.ssh/dropbearkey_rsa source-file ssh-user@ssh-server:/directory

ssh clients

my last post was about my preferred ssh-server. and this post is about my preferred ssh-clients.

ssh-client configuration has to be done at both endpoints - (i) ssh-client computer, and (ii) ssh-server.

dbclient is included within dropbear.

$ dbclient ssh-user@ssh-server
$ scp -S dbclient source-file ssh-user@ssh-server:/directory

though dbclient is very efficient, you might find it lacking sometimes. i couldn't figure out how to forward X.
also, if you do not have dropbear installed, you might not want to install the dropbear server, just to get dbclient.

i much prefer putty, and specifically the cmdline putty-tools. they are a bit quirky to get right the first time. but once setup correctly, you'll love 'em. i like them also because they are much smaller and efficient than openssh-client, the supposedly defacto standard.
putty, though, is very much the defacto choice on windows. there aren't many alternatives.

$ pscp source-file ssh-user@ssh-server:/destination-directory
$ plink ssh-user@ssh-server

enable X!! forwarding
$ plink -X ssh-user@ssh-server
$ xeyes

enjoy! :-)