Enabling tapping support in Gnome 3, I still don’t have support for that at the gdm 3 login prompt .
In /etc/X11/xorg.conf.d/50-synaptics.conf I got tapping support for my mousepad at the gdm3 login prompt by adding
Section "InputClass" Identifier "touchpad catchall" Driver "synaptics" MatchIsTouchpad "on" Option "TapButton1" "1" Option "TapButton2" "2" Option "TapButton3" "3" EndSection
The file wasn’t there, so I created it.
I’ve known for a while the importance of partition alignment both for raid and for the (not so)new 4k harddrives.
Thinking about sector size of 512 bytes VS. 4k for newer drives, I’ve been a bit puzzled by the fact that 512 bytes x 4 = 4k .
I’ve read articles explaining the size of mbr causing unalignment, but I’ve yet to find an article explaining this issue more clear than http://www.thomas-krenn.com/en/wiki/Partition_Alignment .
So I’m installing the latest servicepack from HP on a proliant server running CentOS 6.4 .
Running
# ./hpsum
just died with a returncode of 127 .
Strace is just great for situations like these.
# strace ./cpsum
[...]
old_mmap(0xb30c000, 195144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb30c000
brk(0xb33c000) = 0xb3d9000
open("/lib/ld-linux.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
Sooo I was missing som library. Finding the package that provides that lib is easy:
# yum provides /lib/ld-linux.so.2 [...] glibc-2.12-1.107.el6_4.2.i686 : The GNU libc libraries Repo : updates Matched from: Filename : /lib/ld-linux.so.2 [...]
The hpsum is ELF 32-bit, and I’m running X86-64, so I had to install several 32bit packages:
# yum install glibc.i686 libuuid.i686 libSM.i686 libXrender.i686 fontconfig.i686 zlib-1.2.3-29.el6.i686
Finding out which packages I needed was a matter of running hpsum and a mix of yum search / yum provides / yum install .
I’ve maintained a rather large mail cluster using the Exim mta .
Configuring an MTA is something that is a lot more complicated than one would expect, until you try it. I know Exim now, and aren’t really motivated at learning sendmail or postfix, so I tend to switch to exim as the default mta for any server I administer .
I just did some debugging where a Mojolicious application didn’t send out email, and it turned out the exim ‘sendmail’ compatibility wasn’t 100% compatible with sendmail’s sendmail …
( Long story short: first there was sendmail in every Unix. Then came postfix and exim, but because a lot of Unix utilities already was programmed to using sendmail ‘they’ [postfix and exim] made a sendmail binary/wrapper that accept the same options as sendmail )
Anyway after some debugging I noticed that it seemed like the perl Mail lib was default’ing to adding -t to sendmail . And I had a look in the exim documentation and noticed that they _do_ support -t, but as they wrote:
If the command has any arguments, they specify addresses to which the message is not to be delivered. That is, the argument addresses are removed from the recipients list obtained from the headers. This is compatible with Smail 3 and in accordance with the documented behaviour of several versions of Sendmail, as described in man pages on a number of operating systems (e.g. Solaris 8, IRIX 6.5, HP-UX 11). However, some versions of Sendmail add argument addresses to those obtained from the headers, and the O’Reilly Sendmail book documents it that way. Exim can be made to add argument addresses instead of subtracting them by setting the option extract_addresses_remove_arguments false.
soooo I tried adding
extract_addresses_remove_arguments = true
to exim.conf, and it seem to have solved the problem.
At first I was thinking there had to be a bug in the Apache logrotate script in CentOS 6.4, then I noticed they’ve by default disabled compression of all logs .
$ grep compress /etc/logrotate.conf # uncomment this if you want your log files compressed #compress $
Troubleshooting misbehaving php sites can be a pain.
It’s even more pain when the dev has put
error_reporting(0);
hidden ‘somewhere’ in one of many, many, many php source code files .
sigh
With reference to my post regarding suspend for my samsung laptop, I noticed yesterday that suspend now works. Seems like some update from Ubuntu ( Linux kernel ) has fixed it .
So I’ve been operating FreeBSD servers for about a year now where I work. I’ve come to really like the sockstat command in FreeBSD
# sockstat -l -4
will list every ipv4 address listening in some port and which user the process that is listening to that port is.
In Linux I’ve usually done the same with
# netstat -taupen
netstat -taupen isn’t as ‘clean’ as sockstat in FreeBSD, but I see that
# netstat -tln
give me less info, and I think I’d prefer that one when I simply need to check which ports are in a LISTENING state ( and add -u to show udp as well )
As a kind of followup on my previous post, I’ve been increasingly annoyed by how puppet agent update on my Centos hosts takes a looong time. F.example I’m up in 120 seconds for my LAMP puppet profiles.
I suspected yum to be the slowdown, but my previous post from today gave me a hint that maybe puppet does something IPv6’ish stuff too .
I had a look at
# tcpdump -vvvvv 'port 53'
while doing a puppet update, and I see a lot of:
[myhostname].42349 > ns1.[mydomain].domain: [bad udp cksum 5599!] 18560+ AAAA? puppet.[mudomain]. (36)
15:09:33.326822 IP (tos 0x0, ttl 64, id 61459, offset 0, flags [none], proto UDP (17), length 133)
ns1.[mydomain].domain > [myhostname].42349: [udp sum ok] 18560 q: AAAA? puppet.[mydomain]. 0/1/0 ns: [mydomain]. [50m40s] SOA ns1.[my SOA]. hostmaster.[my SOA]. 1378837114 14400 3600 777600 3600 (105)
So those AAAA request does indeed look like some IPv6 lookups are happening.
Looking at the resolv.conf man page, and with help from wiki.echochat.org I tried adding to
resolv.conf:
[...] options single-request-reopen [...]
and suddenly puppet agent update took roughly 3 seconds, instead of 120 seconds …
Cool ! 🙂
I had this really annoying delay when ssh’ing from one centos 6.4 instance to an other centos 6.4 instance. The ‘usual’
UseDNS no
in /etc/ssh/sshd_config on the server side didn’t resolve the issue. Both the client and the server had proper dns and reverse dns records as well.
The thing that kind of put me off was that I had a situation like this:
$ ssh hostname ( delayed, slow connection) $ ssh FQDN ( delayed, slow connection) $ ssh IP address ( fast, normal connection )
So the symptoms was as if there really _was_ some dns problems …
I found some posts via google pointing out disabling GSSAPIAuthentication could help, which it didn’t in my case when I did that on the server side. But I did notice that disabling GSSAPIAuthentication on the client side did help a bit, but the connection was still delaying a bit compared to using ip only.
To me it still looked a bit like dns problems…
The man ssh_config page gave me a hint regarding AddressFamily:
AddressFamily
Specifies which address family to use when connecting. Valid arguments are “any”, “inet”
(use IPv4 only), or “inet6” (use IPv6 only).
Since we don’t have any working ipv6 dns servers or network, setting AddressFamily to inet + disabling GSSAPIAuthentication on both the client and server completely solved my problem.
We don’t use GSSAPIAuthentication anyway, so I don’t have any problems with disabling that.
so,
/etc/ssh/ssh_config
[..]
GSSAPIAuthentication no
# ipv4 only
AddressFamily inet
[...]
and /etc/ssh/sshd_config
[...]
GSSAPIAuthentication no
[...]
It’s with IPv6 as it is with saving the environment:
you know you have to do something about it, it’s just inconvenient to fix it right now, and it still works the old way so…