Wednesday, November 30, 2011

Query your Switch using SNMP and Linux

So you want to query a switch using snmp to see which MACs are being seen on which ports. In that case you will need the BRIDGE-MIB. On Centos-5 it is supplied, but as part of the 'libsmi' package.

# rpm -qa | egrep 'libsmi|net-snmp' | sort
libsmi-0.4.5-2.el5
net-snmp-5.3.2.2-14.el5_7.1
net-snmp-libs-5.3.2.2-14.el5_7.1
net-snmp-utils-5.3.2.2-14.el5_7.1

So you need to create file '/etc/snmp/snmp.conf' and configure as follows:

# cat /etc/snmp/snmp.conf
mibdirs +/usr/share/mibs/ietf

Then you should have success with the following command.
Remember to use the correct community string - by default its usually 'public'.
And the mib object name IS case sensitive.

# snmptable -v1 -c public -Cbw 80 192.168.24.1 -IR BRIDGE-MIB::dot1dTpFdbTable
SNMP table: BRIDGE-MIB::dot1dTpFdbTable

Address Port Status
0:c:29:45:21:9e 24 learned
0:c:29:79:6c:73 24 learned
0:12:3f:c3:9d:7b 19 learned
0:14:38:a2:70:7e 15 learned
0:14:5e:68:74:ed 17 learned
0:1b:78:22:bc:30 21 learned
0:26:55:e7:5b:f4 27 learned
0:50:56:a7:61:32 22 learned
64:31:50:cd:c7:0 0 self
9c:8e:99:19:99:a6 23 learned
9c:8e:99:c4:46:56 13 learned
c8:4c:75:90:f:e0 28 learned

Status 'self' or 'mgmt' is the MAC of the switch itself - used for the management connection.


If you have a modular switch, you may want to check the logical to physical port name mapping, as show next. If you just have a simple switch, the port names are usually boring!


# snmpwalk -v1 -c public 192.168.24.1 -IR IF-MIB::ifName | head -n 5
IF-MIB::ifName.1 = STRING: 1
IF-MIB::ifName.2 = STRING: 2
IF-MIB::ifName.3 = STRING: 3
IF-MIB::ifName.4 = STRING: 4
IF-MIB::ifName.5 = STRING: 5

Before you run the above commands, it may be useful to ping every host on your subnet, just so that the switch has seen everything. You can use 'nmap' for that:

# nmap -n -sP 192.168.24.0/24

Good luck with the above. I've often found these command very useful!

Friday, August 05, 2011

bash initialisation files

I've been installing Centos 5 into VirtualBox this evening. Due to some mistyping, I ended up in the situation where I needed to manually create the 'home' directory for the user 'nwsmith'. Ok, thats simple, just remember to set the correct user and group, and the correct permissions:

# mkdir /home/nwsmith
# chown nwsmith.nwsmith /home/nwsmith
# chmod 700 /home/nwsmith

But when I logged in as user 'nwsmith' I was not getting the correct bash prompt. It looked like PS1 was not being set correctly. I quickly realised that I was missing the '.bashrc' file from my home directory, so I copied that across from '/etc/skel/.bashrc'.

But still I was not getting the correct prompt. But I found that if I ran the command 'source ./.bashrc' then I did get the correct prompt. Finally the penny dropped, when I googled up this link Initialisation files and configuration from the University of Cambridge Computer Laboratory. I'm just going to quote the paragraph I found really useful:

When bash is invoked as a login shell it first reads and executes commands from the file /etc/profile, if that file exists. This initialises a few environment variables, and calls a set of small initialisation scripts from the directory /etc/profile.d, which will vary depending on the software loaded on the machine (for example, if KDE is loaded there will be one called kde.sh).

After reading that file, it looks for ~/.bash_profile or ~/.bash_login or ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. (The --noprofile option could be used when the shell is started to inhibit this behaviour.)

When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. (This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc).

Thus, by default, the file ~/.bashrc is not read automatically when a login shell is started. For this reason it is usual behaviour to add a section to ~/.profile (or ~/.bash_profile or ~/.bash_login) to read and execute it, so that you get uniform behaviour on both login shells and normal interactive shells.

After reading that I realised that I also need a '.bash_profile' file in my home directory, so I copied one across from '/etc/skel/.bash_profile'. And then when I logged in as user 'nwsmith' I got the prompt I was expecting.

By the way, '.bash_profile' and '.bashrc' do NOT need to have 'x' executable permission.

Friday, July 22, 2011

selinux, ipsec-tools and '/etc/racoon/racoon.conf'

The racoon daemon failed to start, and this message was logged:

# grep denied /var/log/messages
Jul 21 17:57:56 hexgate kernel: type=1400 audit(1311267452.973:4): avc: denied { getattr } for pid=2412 comm="racoon" path="/etc/racoon/racoon.conf" dev=md0 ino=1401757 scontext=system_u:system_r:racoon_t:s0 tcontext=root:object_r:user_home_t:s0 tclass=file

So I guess I had got the wrong security context on the file. To fix it, I did this:

# ls -lZ /etc/racoon/racoon.conf
-rw------- root root root:object_r:user_home_t /etc/racoon/racoon.conf
#
# restorecon -v /etc/racoon/racoon.conf
restorecon reset /etc/racoon/racoon.conf context root:object_r:user_home_t:s0->system_u:object_r:ipsec_conf_file_t:s0
#
# ls -lZ /etc/racoon/racoon.conf
-rw------- root root system_u:object_r:ipsec_conf_file_t /etc/racoon/racoon.conf
#

..and then racoon started Ok.
So what other file security context could be relevant to racoon:

# grep racoon /etc/selinux/targeted/contexts/files//file_contexts
/etc/racoon(/.*)? system_u:object_r:ipsec_conf_file_t:s0
/var/racoon(/.*)? system_u:object_r:ipsec_var_run_t:s0
/var/run/racoon.pid -- system_u:object_r:ipsec_var_run_t:s0
/etc/racoon/certs(/.*)? system_u:object_r:ipsec_key_file_t:s0
/usr/sbin/racoon -- system_u:object_r:racoon_exec_t:s0
/etc/racoon/psk\.txt -- system_u:object_r:ipsec_key_file_t:s0
#

By the way, this was on the following system:

# cat /etc/redhat-release
CentOS release 5.5 (Final)
#
# rpm -qa | grep selinux-policy
selinux-policy-2.4.6-279.el5_5.2
selinux-policy-targeted-2.4.6-279.el5_5.2

Thursday, June 30, 2011

Installing TweetDeck with Adobe AIR on Fedora 15

Unfortunately, there is a problem installing TweakDeck on Fedora 15, and even more unfortunately, it does not look like it will be fixed.

Using the 'TechnoZeal' instructions, I had no difficulty installing Adobe AIR on Fedora 15 (64-bit), although AIR seems to be a 32-bit application and so you will need to install many 32-bit library files.

[nwsmith@fed15-x64 ~]$ rpm -qa | grep -i adobe
adobe-release-i386-1.0-1.noarch
adobeair-2.6.0-19170.i386

I downloaded the latest TweakDeck '.air' file:

[nwsmith@fed15-x64 Downloads]$ ll
-rw-rw-r--. 1 nwsmith nwsmith 2373967 Jun 30 20:46 TweetDeck_0_37.6.air
[nwsmith@fed15-x64 Downloads]$ md5sum -b TweetDeck_0_37.6.air
d8dc9c0fbff37c31c8af6a788854cb25 *TweetDeck_0_37.6.air

..but when you try to install it, it aborts with error message:

Sorry, an error has occured.
The application could not be installed because the installer file is
damaged. Try obtaining a new installer file from the application author.

Eventually I discovered that the 'Adobe AIR Application Installer' was recording a log file:

[nwsmith@fed15-x64 ~]$ cd /home/nwsmith/.appdata/Adobe/AIR/Logs/
[nwsmith@fed15-x64 Logs]$ ll
-rw-rw-r--. 1 nwsmith nwsmith 83863 Jun 30 21:41 Install.log
[nwsmith@fed15-x64 Logs]$ cat Install.log
[Adobe AIR Application Installer:4156][INFO] Application Installer begin with version 2.6.0.19170 on Linux x86
[Adobe AIR Application Installer:4156][INFO] Commandline is:
[Adobe AIR Application Installer:4156][INFO] Installed runtime (2.6.0.19170) located at /opt/Adobe AIR
[Adobe AIR Application Installer:4156][INFO] Cancel request received
[Adobe AIR Application Installer:4156][INFO] Application Installer end with exit code 6
[Adobe AIR Application Installer:4192][INFO] Application Installer begin with version 2.6.0.19170 on Linux x86
[Adobe AIR Application Installer:4192][INFO] Commandline is:
[Adobe AIR Application Installer:4192][INFO] Installed runtime (2.6.0.19170) located at /opt/Adobe AIR
[Adobe AIR Application Installer:4192][INFO] Unpackaging file:///home/nwsmith/Downloads/TweetDeck_0_37.6.air to /tmp/FlashTmp.NhdYfW
[Adobe AIR Application Installer:4192][INFO] Application signature verified
[Adobe AIR Application Installer:4192][INFO] Unpackaging/validation complete
[Adobe AIR Application Installer:4192][INFO] No app located for appID 'TweetDeckFast' and pubID 'FFF259DC0CE2657847BBB4AFF0E62062EFC56543.1'
[Adobe AIR Application Installer:4192][INFO] Converting unpackaged application to a native installation package in /tmp/FlashTmp.wkEIg0
[Adobe AIR Application Installer:4192][ERR] Native installation package creation failed: [ErrorEvent type="error" bubbles=false cancelable=false eventPhase=2 text="Unhandled exception Error: Error creating the package /opt/Adobe AIR/Versions/1.0/Resources/rpmbuilder error : symbol not found: parseSpec, /usr/lib/librpmbuild.so: undefined symbol: parseSpec error :
<-- SNIP-->
File not found: /tmp/FlashTmp.wkEIg0/build/usr/share/app-install/desktop/tweetdeckfast.fff259dc0ce2657847bbb4aff0e62062efc56543.1.desktop" errorID=1]
[Adobe AIR Application Installer:4192][ERR] Application Installer end with exit code 7

So Googling on "symbol not found: parseSpec" we find these links:

...where Panu Matilainen summaries:

"Yes, the entire librpmbuild API has changed in rpm 4.9.x and parseSpec() no
longer exists, it's been replaced by a new saner interface known as
rpmSpecParse(). Air (whatever it is, apparently some Adobe proprietary app)
appears to be cheating against soname changes by using the non-versioned -devel
.so symlink and now gets burned because of it. It'd be much better off
launching rpmbuild than using the librpmbuild API.

And yes, Fedora 15 is using rpm 4.9.x:

[nwsmith@fed15-x64 ~]$ rpm -qa | grep ^rpm | sort
rpm-4.9.0-9.fc15.x86_64
rpm-build-4.9.0-9.fc15.x86_64
rpm-build-libs-4.9.0-9.fc15.i686
rpm-build-libs-4.9.0-9.fc15.x86_64
rpm-devel-4.9.0-9.fc15.i686
rpm-devel-4.9.0-9.fc15.x86_64
rpm-libs-4.9.0-9.fc15.i686
rpm-libs-4.9.0-9.fc15.x86_64
rpm-python-4.9.0-9.fc15.x86_64

So it looks like Adobe need to fix it. Unfortunately, we read here that:

"Note: Beginning June 14 2011, Adobe AIR is no longer supported for desktop Linux distributions."

So I've given up on this. A pity as it would have been really nice to run TweetDeck on Fedora Linux. Anyway now I guess I can remove all those 32-bit libraries I just install, and revert to a 'clean' 64-bit environment.


Status Update: 2011-07-15
Please read Sérgio Basto's comments to this post. Sérgio seems to have found a way around the problem, using Mock. I've not yet tried this for myself, but I will give it a try when I have a few minutes to spare. If anyone else tried this method, please post a comment with your result.


Status Update: 2011-07-22
Chris Beckenbach is reporting success with Sergio's method.

Tuesday, June 14, 2011

DTrace for Linux: Progress, but still a work in progress

A couple of months back, I blog posted on Paul Fox's port of DTrace to Linux. I've continued to play around with it since then, and so I think its about time for another blog post about it.

Certainly now there is no problem compiling DTrace for Linux on Fedora 14 with the 2.6.35 kernel, provided you install the necessary dependencies that I listed in the previous post. Since my initial report, I've exchanged many emails with Paul, and he had been able to incorporate in the code the necessary fixes to support compiling on Fedora.

Paul has spent a lot of time recently on the cross-call (aka xcall) problem, and you can read the details on Paul's blog. Certainly this is a challenging area, and although there are still some issues, it looks to me like Paul is determined to fully resolve the issues.

Ok, so let's give DTrace for Linux a bit of a work out and discover a little bit more about it.

After compiling, with 'make all' and installing with 'make install', you load
the DTrace module, with 'make load'.

# uname -a
Linux fed14-64 2.6.35.13-91.fc14.x86_64 #1 SMP Tue May 3 13:23:06 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
# make load
tools/load.pl
21:41:23 Syncing...
21:41:24 Loading: build/driver/dtracedrv.ko
21:41:25 Preparing symbols...
21:41:25 Probes available: 319433
21:41:30 Time: 7s

So you can see there are a lot of probes available. Let's look at a break down:

# dtrace -l | awk '{ print $2 }' | sort | uniq -c | sort -n
1 PROVIDER
3 dtrace
4 io
17 profile
1270 syscall
63808 fbt
254330 instr

You can see that most of the probes come from the 'instr' provider, which I believe is unique to the Linux port of DTrace. And note that the number of providers available is less than what is available on Solaris and FreeBSD.

Let's list the probes, where there are only a small number of probes for the providers:

[root@fed14-64 ~]# dtrace -l -n dtrace:::
ID PROVIDER MODULE FUNCTION NAME
1 dtrace BEGIN
2 dtrace END
3 dtrace ERROR
[root@fed14-64 ~]# dtrace -l -n io:::
ID PROVIDER MODULE FUNCTION NAME
4 io do_sync_read start
5 io do_sync_read done
6 io do_sync_write start
7 io do_sync_write done
[root@fed14-64 ~]# dtrace -l -n profile:::
ID PROVIDER MODULE FUNCTION NAME
254912 profile profile-97
254913 profile profile-199
254914 profile profile-499
254915 profile profile-997
254916 profile profile-1999
254917 profile profile-4001
254918 profile profile-4999
254919 profile tick-1
254920 profile tick-10
254921 profile tick-100
254922 profile tick-500
254923 profile tick-1000
254924 profile tick-5000
319429 profile tick-1ms
319430 profile tick-1s
319431 profile tick-5s
319432 profile tick-10s

Now let's give a breakdown of the number of probes available for each modules for the FBT (Function Boundary Tracing) provider. This will give you an idea of what kernel modules I have loaded on my test system.

[root@fed14-64 dtrace-20110404]# dtrace -l -P fbt | awk '{print $3}' | sort | uniq -c | sort -n
1 MODULE
12 freq_table
13 output
14 speedstep_lib
15 iTCO_vendor_support
15 p4_clockmod
23 i2c_i801
29 ppdev
30 i2c_algo_bit
31 iTCO_wdt
33 snd_page_alloc
37 snd_seq_device
37 soundcore
41 dcdbas
41 snd_hwdep
61 sata_sil24
63 microcode
79 snd_hda_intel
83 parport_pc
99 snd_timer
100 drm_kms_helper
109 video
138 scsi_transport_spi
141 i2c_core
155 parport
199 snd_hda_codec_idt
337 ttm
357 snd
357 tg3
359 snd_seq
420 fuse
424 aic7xxx
490 snd_hda_codec
495 snd_pcm
744 e1000e
867 drm
1671 ipv6
1875 nouveau
52615 kernel

As you can see from the above, I have two different network interface cards in my system. One is a Broadcom, supported by the 'tg3' module, and the other is an Intel card, supported by the 'e1000e' module.

Lets list the probes available for one of the FBT modules:

# dtrace -l -n fbt:p4_clockmod::entry
ID PROVIDER MODULE FUNCTION NAME
310254 fbt p4_clockmod cpufreq_p4_get entry
310256 fbt p4_clockmod cpufreq_p4_setdc entry
310258 fbt p4_clockmod cpufreq_p4_target entry
310260 fbt p4_clockmod cpufreq_p4_verify entry
310262 fbt p4_clockmod cpufreq_p4_cpu_init entry
310264 fbt p4_clockmod cpufreq_p4_exit entry
310266 fbt p4_clockmod cpufreq_p4_cpu_exit entry
310268 fbt p4_clockmod cleanup_module entry
# dtrace -l -n fbt:p4_clockmod::return
ID PROVIDER MODULE FUNCTION NAME
310255 fbt p4_clockmod cpufreq_p4_get return
310257 fbt p4_clockmod cpufreq_p4_setdc return
310259 fbt p4_clockmod cpufreq_p4_target return
310261 fbt p4_clockmod cpufreq_p4_verify return
310263 fbt p4_clockmod cpufreq_p4_cpu_init return
310265 fbt p4_clockmod cpufreq_p4_exit return
310267 fbt p4_clockmod cpufreq_p4_cpu_exit return

Ok, enough of listing probes! Let show some simple DTrace one-liners in action on Linux:

# dtrace -n 'syscall:::entry { @num[execname] = count(); }'
dtrace: description 'syscall:::entry ' matched 635 probes
^C
audispd 1
udisks-daemon 6
rtkit-daemon 8
gnome-settings- 9
abrtd 10
console-kit-dae 10
hald-addon-acpi 12
sendmail 14
gnome-screensav 15
sshd 17
crond 18
dbus-daemon 18
gnome-panel 33
gnome-power-man 38
clock-applet 49
gvfs-afc-volume 60
metacity 68
irqbalance 120
nautilus 157
gedit 362
dtrace 1553
Xorg 10039
firefox 12083
#
# dtrace -n 'syscall:::entry { @num[probefunc] = count(); }'
dtrace: description 'syscall:::entry ' matched 635 probes
^C
rt_sigreturn 1
brk 2
getdents 2
select 6
stat 8
nanosleep 11
rt_sigaction 16
munmap 18
close 21
fstat 21
mmap 21
inotify_add_watch 26
open 32
rt_sigprocmask 32
ioctl 49
write 195
poll 525
read 736
futex 1283
#
# dtrace -n 'fbt:e1000e::entry { @num[probefunc] = count(); }'
dtrace: description 'fbt:e1000e::entry ' matched 373 probes
^C
e1000_clean 17
e1000_clean_rx_irq 17
e1000_clean_tx_irq 17
e1000_desc_unused.clone.26 17
e1000_intr_msi 17
e1000_irq_enable 17
e1000_watchdog 17
e1000_watchdog_task 17
e1000e_get_laa_state_82571 17
e1000e_has_link 17
e1000e_update_adaptive 17
e1000e_update_stats 17
napi_schedule_prep 17
test_and_set_bit 17
e1000_ioctl 34
e1000_get_stats 411

Here is the 'instr' provider in action:

# dtrace -n 'instr:e1000e:: { @num[probefunc] = count(); }'
dtrace: description 'instr:e1000e:: ' matched 3472 probes
^C

e1000_get_drvinfo-je 1
e1000_get_drvinfo-jne 1
e1000e_get_sset_count-ja 3
e1000_get_drvinfo-callr 5
e1000_clean_rx_irq-callr 27
e1000_clean_rx_irq-je 27
e1000_desc_unused.clone.26-jbe 27
e1000_irq_enable-je 27
e1000_watchdog-callr 27
e1000e_get_laa_state_82571-jne 27
e1000e_update_adaptive-jbe 27
e1000e_update_adaptive-je 27
e1000e_update_adaptive-jne 27
e1000e_update_stats-jbe 27
napi_schedule_prep-callr 27
napi_schedule_prep-jne 27
test_and_set_bit-lock 27
e1000_clean-jne 54
e1000_intr_msi-callr 54
e1000_intr_msi-je 54
e1000e_has_link-je 54
e1000e_update_stats-ja 54
e1000_clean-callr 81
e1000_clean-je 81
e1000_watchdog_task-jne 81
e1000_clean_tx_irq-je 108
e1000_watchdog_task-je 108
e1000_watchdog_task-callr 189

One of the aspects that Paul has been developing recently is a suite of test programs that can be used to stress test the system, and expose any problems with the DTrace for Linux port. To try this out, run 'make test'.

Ok, I'm out of time for tonight. Hopefully I can find time for some more post to this blog soon.

Thursday, March 31, 2011

Trying DTrace for Linux on Fedora 14

Some months, or even years ago, I noticed that Paul Fox, the author of the CRiSP editor, was working on a port of DTrace to Linux. Paul seems to have started work on this port back at the start of 2008. He has made regular progress reports on his website blog, and from June 2010, he also started using Google's blogger, which did seem to have taken over as Paul's main blog, but now I notice he has put all the blogger posts back on his website blog!

In February 2011, I finally go around to trying out the code.

Paul seems to be developing on/for Ubuntu, but I wanted to try it on Fedora 14. I had a number of problems, first indentifying which RPM packages I needed to install for the build. And then there were various compile problems, and it took me a while to figure out how to resolve these problems, as I would not claim to be any sort of expert on this.

Here is a list of the RPM packages I needed to install to get the code to compile:

binutils-devel
elfutils-libelf-devel
kernel-devel
libdwarf
libdwarf-devel
libdwarf-static
zlib-devel

I was eventually able to work out the necessary patches to get it to compile on Fedora 14. I did try emailing Paul to give him some feedback, and I think he may have read my emails, but so far I have never received a reply back from him!

Here for posterity, I publish my patch, just to prove I did some work! But note that this is already out of date, as Paul's DTrace for Linux port has continued to moved on.
$ diff -uNr dtrace-20110215 dtrace-20110215.fed14/
diff -uNr dtrace-20110215/cmd/ctfconvert/dwarf.c dtrace-20110215.fed14/cmd/ctfconvert/dwarf.c
--- dtrace-20110215/cmd/ctfconvert/dwarf.c 2010-08-24 23:34:26.000000000 +0100
+++ dtrace-20110215.fed14/cmd/ctfconvert/dwarf.c 2011-03-18 01:19:57.786335906 +0000
@@ -88,9 +88,9 @@
#include <errno.h>
#include "linux.h"
#include <libelf.h>
-#include <libdwarf.h>
+#include <libdwarf/libdwarf.h>
#include <libgen.h>
-#include <dwarf.h>
+#include <libdwarf/dwarf.h>

#include "ctf_headers.h"
#include "ctftools.h"
diff -uNr dtrace-20110215/cmd/ctfconvert/makefile dtrace-20110215.fed14/cmd/ctfconvert/makefile
--- dtrace-20110215/cmd/ctfconvert/makefile 2010-10-17 17:55:26.000000000 +0100
+++ dtrace-20110215.fed14/cmd/ctfconvert/makefile 2011-03-18 01:19:23.255448742 +0000
@@ -44,7 +44,7 @@
LIBS = ../../build/libctf.a -ldwarf -lbfd -lelf -lz

all:
- @if [ ! -f /usr/lib/libdwarf.a ]; then \
+ @if [ ! -f /usr/lib64/libdwarf.a ]; then \
echo "=================================================================" ; \
echo "=== You need /usr/lib/libdwarf.a and /usr/lib/libbfd.a installed to build." ; \
echo "=== " ; \
diff -uNr dtrace-20110215/tools/build.pl dtrace-20110215.fed14/tools/build.pl
--- dtrace-20110215/tools/build.pl 2011-01-26 23:36:06.000000000 +0000
+++ dtrace-20110215.fed14/tools/build.pl 2011-03-19 14:16:48.725192127 +0000
@@ -59,7 +59,7 @@
}

if (! -f "/usr/include/gelf.h") {
- print "Error: you dont appear to have /usr/include/elf.h, which means\n";
+ print "Error: you dont appear to have /usr/include/gelf.h, which means\n";
print "compilation will fail. You should add the libelf-dev package to\n";
print "your system and retry the 'make all'.\n";
exit(1);
diff -uNr dtrace-20110215/tools/mkctf.sh dtrace-20110215.fed14/tools/mkctf.sh
--- dtrace-20110215/tools/mkctf.sh 2010-08-26 10:03:21.000000000 +0100
+++ dtrace-20110215.fed14/tools/mkctf.sh 2011-03-18 01:21:59.600884493 +0000
@@ -19,11 +19,11 @@
cd $build_dir
cmd=`grep '^cmd_' $pwd/build/driver/.cpu_x86.o.cmd |
sed -e 's/^.* := //' |
-sed -e 's/-Wp,-MD[^ ]* /-g /' |
+sed -e 's/-Wp,-MD[^ ]* /-gdwarf-2 /' |
sed -e 's/\\\\//g' |
sed -e 's/cpu_x86/ctf_struct/g' `
#echo $cmd
eval $cmd
cd $pwd
-build/ctfconvert -L label -o build/linux-$BUILD_KERNEL.ctf build/driver/.tmp_ctf_struct.o
+build/ctfconvert -L label -o build/linux-$BUILD_KERNEL.ctf build/driver/ctf_struct.o
ls -l build/linux-$BUILD_KERNEL.ctf

And here is a very quick and basic test, to show DTrace running:

# uname -a:
Linux fed14-64 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
# make load
tools/load.pl
01:26:50 Syncing...
01:26:50 Loading: build/driver/dtracedrv.ko
01:26:52 Preparing symbols...
01:26:52 Probes available: 314700
01:26:56 Time: 6s

# dtrace -n BEGIN
dtrace: description 'BEGIN' matched 1 probe
CPU ID FUNCTION:NAME
1 1 :BEGIN
^C

Admittedly, that is the most basic DTrace one-liner you can possibly try. But I did also try a few 'syscall' one-liners, mostly with success.

Anyway, once I got this going, I wanted to try with Paul's latest release of the code, to get his latest bug fixes, but I was stopped in my tracks, as his FTP site was down. And it continued to be down, for over a week, which was quite frustrating. I tried emailing him, and leaving a blog comment, but again, I got no response. And there was no mention of this problem on his web sites, or blog.

Eventualy, while Googling, I discovered that Paul has a Twitter account, and that he had announced there, that he has a new host name for his FTP site. There is no mention of Paul's Twitter account on his web sites or blogs, at this moment. So I will publicize it here, as he does seem to make good use of it to report progress with DTrace for Linux:
http://twitter.com/#!/crispeditor

And for anyone wanting to try compiling the DTrace for Linux code, please note the new download site is:
ftp://crisp.dyndns-server.com/pub/release/website/dtrace/


Ok, so now I guess I had better download the latest release of the code, and try it out.

Thursday, January 27, 2011

selinux, hwclock and /etc/adjtime

If you are having problems with hwclock, you may want to remove the file '/etc/adjtime' and let hwclock recreate the file, for reasons discussed here:

"hwclock never updates drift factor in /etc/adjtime if time is always set more than once a day"

However, if you have selinux enabled, with an enforcing targeted policy, this will result in the wrong file security context. Here is how to fix it:

# ls -Z /etc/adjtime
-rw-r--r-- root root root:object_r:etc_t:s0 /etc/adjtime

# restorecon -v /etc/adjtime
restorecon reset /etc/adjtime context root:object_r:etc_t:s0->system_u:object_r:adjtime_t:s0

# ls -Z /etc/adjtime
-rw-r--r-- root root system_u:object_r:adjtime_t:s0 /etc/adjtime

# grep adjtime /etc/selinux/targeted/contexts/files/file_contexts
/etc/adjtime -- system_u:object_r:adjtime_t:s0