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…
So I’ve got this Samsung X900 laptop where Ubuntu won’t suspend ( automatically ) when I close the lid . Ubuntu already has this documented at help.ubuntu.com , and by the way : impressive docs Ubuntu ! .
It seems to be possible to fix this with a samsung firmware upgrade , but that exe file seem to be for windows only ( looking into that later ) .
For now I found this nice little hint over at askubuntu.com, I can manually suspend the machine from cli with
$ dbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower org.freedesktop.UPower.Suspend
So I just mapped that command to Alt+s via custom keyboard shortcuts in Ubuntu settings, and I’m 99% satisfied .
I’ll reach for 100% satisfaction later when I’ll go for that windows firmware update .
I’ve been increasingly worried about one of the media servers I backup, the backup time has been crawling it’s ways from 12 to about 14 hours as of today. It’s not that it’s so many TB’s, only 1.4 TB actually, the problem is that there is more than 2 000 000 small files, and rsync have to fstat every one of them. So even when there hasn’t been much change the backup takes longer and longer.
So yesterday I figured I should try out zfs. The media server is already on zfs, and I use zfs on the backup server + I have already got a zfs sync script which I modified some months ago to use mbuffer for maximum bandwith utilization .
And how did this turn out ? well, the backup time went from about 14 hours to 7 seconds … I just realised I could never go away from zfs for these kind of setups (backing up millions of files ) .
When I want to umount a filesystem in Linux and the kernel says it can’t umount because the filesystem is busy I usually do something like
# lsof | grep [mount point]
To figure out what files are open in the mount point .
In FreeBSD you may install lsof or you could instead use the builtin fstat command that comes bundled with FreeBSD . For cases like the one mentioned above fstat with the -f switch is really handy:
# zfs destroy tank/data cannot unmount '/tank/data': Device busy # # fstat -f /tank/data USER CMD PID FD MOUNT INUM MODE SZ|DV R/W www java 1674 4 - 20595308 -rw-r--r-- 19269164 r www java 1674 5 - 20595308 -rw-r--r-- 19269164 r #
I keep forgetting to install the corresponding VirtualBox modules in Fedora when I get a kernel upgrade. Since Fedora uses systemd, which I’m kinda a n00b at I end up google’ing this over and over.
After rebooting to a new kernel, realising I can’t load a virtual machine in VirtualBox, I yum install the corresponding kmod-VirtualBox-3.10.[something] , but there’s no init script in /etc/init.d like I’m used to. systemctl -a and grepping for anything related to vbox doesn’t show anything either !
But it seem to be the systemd-modules-load service that check and load modules, so reloading that service will load the VirtualBox modules
# systemctl restart systemd-modules-load.service
Thanks forums.virtualbox.org