A useful tcpdump command is the following:
tcpdump port 554 -xX -s 0 -l | tee tcpdump.out
When you want to see the specific messages of a protocol, in this case RTSP running on default port 554, this command shows you the output in “human” readable form.
The -s 0 shows the whole packet. The -x also shows the packet in hex.
Former Unix programmers are probably familiar with the dircmp command for comparing two directories. Early versions of Linux didn’t have anything like it which was frustrating. In later versions of Linux, you can use the diff command to recursively compare directories. It’s not exaclty like dircmp, but close enough:
diff -q -r . /otherDir
It can be real frustrating to debug a process with gdb only to have it fork and the child fails. You get left with a process that doesn’t matter. Solving this problem is very easy, you just need to “follow the child”:
set follow-fork-mode child
One of our clients had a project that included C for embedded systems, Java, and C++ thrown in (mostly for unit testing). One of the tasks was to investigate code coverage tools for the C portion which led us to gcov (see gcov(1)). During the build for gcov, we encountered the following link errors:
/usr/bin/ld: obj/Test_function: hidden symbol `__gcov_init’ in /usr/lib/gcc/i386-redhat-linux/3.4.5/libgcov.a(_gcov.o) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
This occurred when the C++ was being linked to our application’s shared libs.
After some investigation, the solution came via the gcc(1) description for -shared option:
… For predictable results, you must also specify the same
set of options that were used to generate code (-fpic, -fPIC, or
model suboptions)…
The gcov parameters in this case are -fprofile-arcs and -ftest-coverage. These parameters were added with the -fPIC option for gcc -shared for the shared libraries. Then the code was able to link and run properly.
Often, telnet is used to test a server listing on a TCP port because if telnet can connect, then you know the server is listening. With simple text protocols like POP, you can do pretty extensive testing with telnet by just typing in commands. Testing a server that supports SSL can be done with the stunnel program. You need to download the pem file with the key and certificate, but after that, it isn’t much different than using telnet.
terry@m38:~$stunnel -c -r www.jeeptech.com:995 -p pop3.pem
+OK Hello there.
user terry
+OK Password required.
pass cleartextPasswd
+OK logged in.
list
+OK POP3 clients that break here, they violate STD53.
1 3721
2 5873
3 1020
4 15425
5 1955
6 8598
7 18708
.
quit
+OK Bye-bye.
terry@m38:~$
The order of contents of the .pem file is, it should contain the unencrypted private key first, then a signed certificate. There should be empty lines after the certificate and private key. Any plaintext certificate information appended on the top of generated certificate should be discarded.
—–BEGIN RSA PRIVATE KEY—–
[encoded key]
—–END RSA PRIVATE KEY—–
[empty line]
—–BEGIN CERTIFICATE—–
[encoded certificate]
—–END CERTIFICATE—–
[empty line]
After installing bogofilter, integrating with postfix was fairly straightforward by following the steps in /usr/share/doc/bogofilter/integrating-with-postfix with minor tweaks.
The document shows you how to set up a script that will have bogofilter filter incoming mail. As identified in the bogofilter man page, you can have the result of the filter do a variety of things like add header lines with spam/non-spam ratings, add text to subject lines, automatically update your spam/non-spam dictionary, etc. I configured the script to add text to subject lines based on if bogofilter classified the mail as spam or unsure (non-spam goes through without any subject line change).
The only clarification to the integrating-with-postfix document was to make sure that the /var/spool/filter directory is owned by user filter user with permissions 0×755.
The only change to the bogofilter config in /etc/bogofilter.cf was to uncomment the “spam_subject_tag” and the “unsure_subject_tag” so those were turned on.
The /etc/postfix/master.cf file launches the necessary scripts for bogofilter as described in the integrating-with-postfix document.
If you want to escape the GUI in Linux, press ctrl-alt-F1 to get a tty style terminal session. There are at least six tty style sessions using the other function keys up to ctrl-alt-F6. Ctrl-alt-F8 will bring back the GUI. In Red Hat, it seems like it preserves the GUI, but under Ubuntu, your current GUI session is lost. Escaping the GUI is handy if it hangs or the mouse isn’t working. From the tty session, the machine can be repaired or rebooted cleanly.
If you are configuring a Linux box as a server, it is convenient to configure it to boot into terminal mode rather than GUI mode. This is especially true if it is hooked up to a KVM because Linux seems to get confused when it is hooked up to a KVM and the mouse won’t work. On RedHat boxes the default run state needs to be changed from 5 to something like 3 in the /etc/inittab file. For example:
id:3:initdefault:
On a Ubuntu box (and I assume all Debian boxes are like this), the default runstate is 2 and the GUI is started in all runstates except 1. This is the case if you load Ubuntu as a desktop which I generally do because it is nice to have the GUI to configure the server. In order to disable the GUI in runstate 2, don’t just remove the start script, move it so that the start script does not get recreated during an update:
cd /etc/rc2.d mv S13gdm K01gdm
Any time you want to start up the GUI, all you need to do is change the runstate to a runstate that has the GUI.
init 5
Sometimes it can be tough debugging a program built with a cross compiler for an embedded system. The embedded system might not have enough memory to run gdb. It probably has enough memory to run gdbserver though and this can be extremely handy.
The first step of running a remote gdb session with gdbserver is building gdb for the target platform that runs on the host. Download your desired gdb version and configure it something like this:
./configure --target="target-cpu" --host=i686-host_pc-linux-gnu --with-headers=/path/to/headers/for/cross/compiler
On the embedded system, run your process under gdbserver and specifiy a port to listen to:
$ gdbserver host:1234 a.out
On your development system with the source code, run the gdb that you built.
$ ./gdb a.out gdb> target remote 10.0.1.1:1234 gdb> c
In the commercial world, there seems to be a lot more Red Hat than Debian work, so a lot of people end up doing a lot more rpming than apt-getting. But, who wants to load Red Hat or Fedora at home when they could load a Debian based distro like Ubuntu. The tough part is bouncing back and forth on the installation commands. It always seems like the GUI tools don’t cut it.
The following lists are Red Hat first, Debian second.