Well, now that Google Chrome is available on Debian:

deb http://dl.google.com/linux/deb/ stable non-free main

is mighty fast and already has a FlashBlock plugin:

http://userscripts.org/scripts/show/46673

and something that claims to work like AdBlock+ :

http://www.adsweep.org/

I am jumping ship...

The reason? I cannot believe Firefox, or any other browser for that matter, would use a single process for everything, including external plugins like flash or, God forbid, Java. That means if one of your 10 open tabs is launching a Java applet, which tries to connect to some URL, which is temporarily unavailable - the whole browser will hang for minutes!

In Chrome, that never happens.

Dear lazyweb,

I've got a server ( actually CentOS 5 w/ SSH 4.3 ).
The problem with it is that whenever I try to log in ( using a password ) the login is very slow, takes about 10 seconds.

More precisely,

utumno:/home/leszek# ssh -vvv 192.168.65.14
OpenSSH_5.1p1 Debian-7, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /home/root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.65.14 [192.168.65.14] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /home/root/.ssh/identity type -1
debug1: identity file /home/root/.ssh/id_rsa type -1
debug1: identity file /home/root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-7
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 134/256
debug2: bits set: 530/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 24
debug1: Host '192.168.65.14' is known and matches the RSA host key.
debug1: Found key in /home/root/.ssh/known_hosts:24
debug2: bits set: 513/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/root/.ssh/identity ((nil))
debug2: key: /home/root/.ssh/id_rsa ((nil))
debug2: key: /home/root/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/root/.ssh/identity
debug3: no such identity: /home/root/.ssh/identity
debug1: Trying private key: /home/root/.ssh/id_rsa
debug3: no such identity: /home/root/.ssh/id_rsa
debug1: Trying private key: /home/root/.ssh/id_dsa
debug3: no such identity: /home/root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@192.168.65.14's password: 
debug3: packet_send2: adding 64 (len 56 padlen 8 extra_pad 64)
debug2: we sent a password packet, wait for reply

<---- HERE IT HANGS FOR ABOUT 10 SECONDS

debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 38400
debug1: Sending environment.
debug3: Ignored env ORBIT_SOCKETDIR
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env XDG_SESSION_COOKIE
debug3: Ignored env GTK_RC_FILES
debug3: Ignored env WINDOWID
debug3: Ignored env GTK_MODULES
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env GNOME_KEYRING_SOCKET
debug3: Ignored env USERNAME
debug3: Ignored env SESSION_MANAGER
debug3: Ignored env _JAVA_OPTIONS
debug3: Ignored env MAIL
debug3: Ignored env PATH
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env GDM_XSERVER_LOCATION
debug3: Ignored env PWD
debug3: Ignored env GNOME_KEYRING_PID
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env GDM_LANG
debug3: Ignored env PS1
debug3: Ignored env GDMSESSION
debug3: Ignored env HISTCONTROL
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LS_OPTIONS
debug3: Ignored env GNOME_DESKTOP_SESSION_ID
debug3: Ignored env LOGNAME
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env LESSOPEN
debug3: Ignored env WINDOWPATH
debug3: Ignored env DISPLAY
debug3: Ignored env LESSCLOSE
debug3: Ignored env COLORTERM
debug3: Ignored env XAUTHORITY
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 131072
debug2: channel_input_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Wed Aug 12 14:23:42 2009 from 192.168.65.20

Has anyone seen something like that?

Dear lazyweb,

I've got a log ( a .txt file) containing a loooong sequence of raw network packets. The log looks like this:

ff ff ff ff ff ff 00 03 91 4b 33 57 08 06 00 01    ..3W....
08 00 06 04 00 01 00 03 91 4b 33 57 0a 27 f4 07    ........3W.'?
00 00 00 00 00 00 0a 27 f4 01 00 00 00 00 00 00    .......'?......
00 00 00 00 00 00 00 00 00 00 00 00                ............

00 13 11 e9 c3 e6 00 03 91 4b 33 57 08 00 45 00    ...橨?.3W..E.
00 2c 00 bc 00 00 40 06 8b 50 0a 27 f4 07 cb 61    .,.?.@..'?犿
25 30 1b 69 00 50 00 0f 72 25 00 00 00 00 60 02    %0.i.P..r%....`.
16 d0 04 a9 00 00 02 04 05 b4                      .??....?

(many more packets here)

I am looking for a tool which would let me import (perfectly the whole file, failing that - one packet at a time ) this data and analyze it. (in similar way Wireshark does it for its captures.)

I've searched the web and came up empty-handed. Any hints?

"The crash has laid bare many unpleasant truths about the United States. One of the most alarming, says a former chief economist of the International Monetary Fund, is that the finance industry has effectively captured our government—a state of affairs that more typically describes emerging markets, and is at the center of many emerging-market crises. If the IMF’s staff could speak freely about the U.S., it would tell us what it tells all countries in this situation: recovery will fail unless we break the financial oligarchy that is blocking essential reform. And if we are to prevent a true depression, we’re running out of time.

by Simon Johnson"


http://www.theatlantic.com/doc/print/200905/imf-advice

Dear lazyweb,

I need your help. Situation: I've got here a little embedded device that is suspected to violate DHCP standards, specifically RFC 2132 section 9.7, and I am supposed to setup a test which will confirm this suspicion.

The section says that DHCPOFFER packages must include an option 'server identifier' which is supposed to be set to the IP of the DHCP server ( sometimes the network is setup in this way that there is a machine which relays all traffic - including DHCP packets - to the clients so they cannot just take a look at source IP of the incoming packets to know where the DHCP server is ). The clients are supposed to use this IP for all subsequent communication with DHCP server.

Now, the embedded device is suspected to ignore the 'server identifier' option and send all subsequent DHCPREQUESTS to the IP from where it got its DHCPOFFER, so if there is a relaying machine in between, the device fails to renew its IP.

I have no access to the original setup where this bug was supposedly detected. All I have here is the device and 1 laptop running, of course, Debian. So I have to

1) produce a DHCPOFFER packet whose source IP would be different than the 'server identifier' option inside it,
2) set the lease time to, lets say, 10 seconds ,
3) sniff the network and see which IP the embedded device uses to renew its lease.

The problem is with 1). There are 3 DHCP servers in Debian: dhcp3-server, dnsmasq and udhcpd. AFAIK, dnsmasq and udhcpd do not even let me configure the 'server identifier' , so looks like my only option is to use 'dhcp3-server'.

So I have set up the server to listen on laptop's eth0 with the following dhcpd.conf: ( eth0's IP is 10.0.0.1 )

(... snip...)

subnet 10.0.0.0 netmask 255.255.255.0 {

  range 10.0.0.3 10.0.0.254;

  option domain-name-servers 192.168.1.60;

  option domain-name "utumno.com";

  option routers 10.0.0.1;

  option broadcast-address 10.0.0.255;

  max-lease-time 10;

  server-identifier 120.30.0.1;

}

I connected the device and everything works: the device gets it's IP, renews it and so on. However, the problem is that dhcp3-server is too clever and as soon as I set the 'server-identifier' option to 120.30.0.1, it starts sending its DHCPOFFER and DHCPACK packets FROM THIS IP, even though it is listening in eth0 which has 10.0.0.1. So for my testing purposes, this setup is useless.

Now, anobody has an idea how can I either

a) force dhcp3-server to produce the desired DHCPOFFER packages?
b) rewrite the source IP with iptables ( iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source=10.0.0.1 doesn't work! Is it because such packets do not go thru NAT? )
c) some other suggestion?

I'd like to kick out all multimedia packages which came from debian-multimedia.org and replace them with versions from Debian proper.

How can I figure out the list of all packages that have been installed from a given repository without manually going over all 1400 of them?

... some do it in unusual ways:

http://dimir.eu/fun/debian.jpg

I've got two machines, 'utumno' and 'angband'. 'Utumno' is directly connected to DSL modem and is visible from The Internets; 'angband' is not visible but it is connected to Utumno via a crossover cable so I can ssh to utumno and from there ssh to angband.

Utumno runs Debian Lenny and OpenSSH 5.1, Angband is an embedded device running DD-WRT and Dropbear 0.51

I've set up authorized keys so I can simply type

utumno@ ssh angband

and that works every single time.

Now, I want to be able to directly connect to Angband from outside, so I thought I'd set up local port forwarding with SSH:

utumno@ ssh -g -L 8022:angband:22 angband

That logs me into angband and seems to forward utumno:8022 to (I hope?) angband:22:

utumno@ netstat -aenp | grep 8022
tcp        0      0 0.0.0.0:8022            0.0.0.0:*               LISTEN      0          9518994     24063/ssh

I thought now I'd be able to log directly to angband by

 ssh -p 8022 utumno

but when I try

utumno@ ssh -vv -p 8022 localhost
OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 8022.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host

and at the same time in angband's console ( the one that I got logged in when I forwarded the ports with ssh -g -L 8022:angband:22 angband ) the following appears

channel 2: open failed: connect failed:

I've tried to Google for 'channel 2: open failed: connect failed:' and 'ssh_exchange_identification: Connection closed by remote host', but no joy...

I've recently come to realize that apt-get and aptitude are not exactly compatible with each other. For example, hold done the 'apt-get way' :

echo "package_name hold" | dpkg --set-selections

will be ignored by aptitude.

Thus a question: can apt-get and aptitude be safely used concurrently? (save the 'hold' incompatibility) I.e. can I install a package with apt-get, remove it with aptitude, update with system with apt-get, then upgrade it with aptitude? What about other package managers, like synaptic, adept? Can they be mixed with apt-get?

The last 3 months I've been helping in one of Debian's newbie forums.

Over there, I discovered a phenomenon I didn't know exist: a lot of people, upon a successful installation, don't (know they have / bother) to edit their sources.list and go on for YEARS with just the CDROM in there ( and they don't even know they should have that inserted if they want to upgrade anything )

Every day I see a couple of lost souls claiming that 'apt doesn't work', and now my standard reply is 'show your sources.list'.

This is real. Debian Installer really needs to stress the need to edit one's sources.list !!