Category Archives: linux
If you’ve ever encountered this, you probably spent a fair amount of time scratching your head over it before it got resolved. Recently, I’ve seen this issue arise twice with clients, so I figured it was time to document it so that perhaps a google search might hit this record and help others.
If you’re currently finding that your curl requests resolve to your server rather than giving you a “Couldn’t resolve host” error, I’m betting the following details are true:
1) You have a wildcard DNS entry for your domain
2) That domain with the wildcard entry is your “search” line in /etc/resolv.conf
What this looks like:
First, we pick a domain we know doesn’t exist:
(~) # dig thisdontexistanywhereatall.com +short
Then we curl it:
(~) # curl -I thisdontexistanywhereatall.com
HTTP/1.1 301 Moved Permanently
Date: Sun, 21 Feb 2016 19:44:33 GMT
Server: Apache/2.2.15 (CentOS)
Content-Type: text/html; charset=iso-8859-1
What? Why is a non-existent domain being responded to by MY server?
What’s happening is this:
A) The curl request looks up the domain and finds no record for it
B) the DNS libraries called then assume that it might be a subdomain and so it checks the search domain defined in /etc/resolv.cnf
C) because there is a wildcard DNS entry for my domain, it results in a match for thisdontexistanywhereatall.com.darke.net
To fix this, you can simply append a . to the end of the domain you are curling. This keeps step B and C from happening:
(~) # curl thisdontexistanywhereatall.com.
curl: (6) Couldn't resolve host 'thisdontexistanywhereatall.com.'
To prevent having to append that . each and every time, you can also elect to put a domain without a wildcard DNS entry in the /etc/resolv.conf.
Hopefully this helps the next guy.
One of the more useful tools in helping to locate when/where a server was compromised are manual anti-virus scans. Additionally, a great hurdle to put up in front of malicious attackers is a scanner that scans files as they are created/modified to check for malicious content.
In the linux world, there’s not always a great understanding of what options are available, so I’m very briefly going to outline three that I am aware of and/or use.
The three I am going to cover are:
So… if you’re looking at this post, it is because you’ve spent the last 2 hours pulling your hair out trying to figure out how to make your Mac’s EFI boot loader recognize a FULL linux install (not a “live” cd) on a USB drive. Something that used to be pretty painless to do for most systems, but the EFI component is driving you up a wall.
I just got done doing it, thanks to a pointer from a co-worker.
You need two items:
1) A thumb drive that you can put an EFI bootable OS onto (the fedora LIVE cd seems to do this automatically)
2) Your *actual* target USB drive
I was able to boot into the smaller thumb drive LIVE environment and then install onto my target USB drive. Doing so created the correct EFI components that allows MacOS to see the drive when you boot up and hold down the option key.
This was done with Fedora. I can’t speak to the other OSes and their LIVE cds.
I made a quick change on a client’s iptables configuration and went to save the iptables rules out when I encountered an error I’d never seen before:
iptables: Saving firewall rules to /etc/sysconfig/iptables: /etc/init.d/iptables: line 274: restorecon: command not found
A quick search later, I found it was fairly easy to resolve. There was just a missing package:
[root@server ~]# yum install policycoreutils
And all was well…
So, yesterday, a co-worker and I were scratching our heads about a plesk issue we ran into. A client had been upgraded from an older plesk to plesk 10.4.4. In the process, their chrooted SFTP accounts stopped working. Attempting to su to those users gave:
# su – username
system error: No such file or directory
When I picked up the escalation, I went right to the usual chroot issues. Permissions, ownership, etc. No dice. I noticed that the users shared a UID with another user, but after a quick manual change to see if that impacted it, still no dice. Another co-worker found that the issue was indeed the UID, but you had to run a series of commands afterwards. I wanted to document this here so that future people searching google for this error will see something other than the useless “cron” related posts on the plesk forums that I was wading through yesterday. :p
1) Change the UID of the user
2) /usr/local/psa/admin/sbin/chrootmng --remove --source=/var/www/vhosts/chroot --target=/path/to/chrooted/users/home/directory
3) rm -rf /path/to/chrooted/users/home/directory/etc
(for some reason --remove leaves this folder behind)
4) /usr/local/psa/admin/sbin/chrootmng --create --source=/var/www/vhosts/chroot --target=/path/to/chrooted/users/home/directory --setup-user username
That should get your chroot SFTP users back up and running if you encountered the same error. Big thanks to the co-worker that found the ultimate order of items and wasn’t thrown off the track of the UID issue like I was… and may our frustration save the rest of you out there in google land a bit of time.
However, be warned! Plesk no longer supports chrooting for users other than the primary FTP user of the domain. As a result of this, you are going to run into permission issues with your subusers that you used to have sharing the UID. You’re going to need to learn about setting up ACL rules to counteract this.
So it turns out I need to spend a little bit more time investigating the available yum plugins for the Redhat centric distros. After a little bit of time banging my head against not finding an update for a package I knew was there (and verifying there was no exclude set in /etc/yum.conf), I finally tripped across a page describing how to set up version locks in yum.
- Install the plugin: yum install yum-versionlock
- Enable it: make sure enabled = 1 appears in /etc/yum/pluginconf.d/versionlock.conf
- Add the packages you want to lock to /etc/yum/pluginconf.d/versionlock.list , including version and architecture. For example: mysql-5.1.52-1.el6_0.1.x86_64. You can also use wildcards, such as: mysql-5.1.52-1.el6_0.1.*
- Test it by trying to update a locked package: yum update mysql
Turns out this is what the client had done and I got to walk away learning something new. Always a good day when that happens.
Neat. It turns out the leap second this particular weekend DID matter. Those of you will dell machines seeing the OSM software freak out and spike your CPU for no reason? Manually reset your date and restart the service.
date; date `date +"%m%d%H%M%C%y.%S"`; date; service dsm_om_connsvc restart;
This is fairly straight forward and surprisingly simple:
First, get the dependency out of the way:
yum install httpd-devel
Once you have that package (and its dependencies), you can then install mod_rpaf.
(you may want to go to http://www.stderr.net/apache/rpaf/download/ just to verify that is still the current version)
tar zxvf mod_rpaf-0.6.tar.gz
apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c
You can then create the file /etc/httpd/conf.d/mod_rpaf.conf, with the following content:
LoadModule rpaf_module modules/mod_rpaf-2.0.so
# mod_rpaf configuration
Be sure to replace X.X.X.X with your proxy IP.
Restart apache and then check your logs to see that you are now seeing the IPs of your visitors rather than the private proxy IP.
I’m usually someone who learns new things because I become irritated with “the way things are”. The following tip is a perfect example. I grew tired of my usb drive going into sleep mode and causing issues with some of the things I use it for, so I decided to see if I could tell it to never go to sleep.
Turns out? You can.
yum install sdparm
sudo aptitude install sdparm
Once that is installed, you can point it at your USB device. In my case, it was /dev/sdc. If you’re unsure what device it has been labeled as, consult the output of “dmesg” and find it.
So, point sdparm to it with the command: sdparm -a
[root@pinja ~]# sdparm -a /dev/sdc
/dev/sdc: Seagate FreeAgentDesktop 100F
Power condition mode page:
PM_BG 0 [cha: n, def: 0, sav: 0]
STANDBY_Y 0 [cha: n, def: 0, sav: 0]
IDLE_C 0 [cha: n, def: 0, sav: 0]
IDLE_B 0 [cha: n, def: 0, sav: 0]
IDLE 0 [cha: n, def: 0, sav: 0]
STANDBY 1 [cha: y, def: 1, sav: 1]
ICT 0 [cha: n, def: 0, sav: 0]
SCT 9000 [cha: y, def:9000, sav:9000]
Power consumption mode page:
ps_id 0 [cha: n, def: 0, sav: 0]
SAT ATA Power condition mode page:
APMP 0 [cha: n, def: 0, sav: 0]
APM 0 [cha: n, def: 0, sav: 0]
Notice STANDBY_Y has a 0 beside it? That means standby is disabled (because I shut it off earlier). The actual flag can change a bit from drive to drive (some just say STANDBY, for example) so just pay attention to what is listed there. If you find it has a 1, you will need to run the commands:
sdparm --command=start /dev/sdc
sdparm --clear STANDBY_Y -6 /dev/sdc
sdparm -save -6 /dev/sdc
Another “sdparm -a /dev/sdc” should then show you the cleared value and we’ve saved it so it will persist through a reboot.
Ran into this one today for a client and it has been such a long time since I had to do any NAT routing with iptables, it took me a bit to suss it out again how it was done properly. In light of that, documenting it here so it is easier to find 5 years from now when I need to do it again. 😉
Set forwarding in sysctl.cnf:
net.ipv4.ip_forward = 1
Then set the two rules. One to route the traffic to the remote host and the other to route it back:
# iptables -A PREROUTING -t nat -p tcp -d ip.of.box.1 –dport 3306 -j DNAT –to-destination ip.of.box.2
# iptables -A POSTROUTING -t nat -p tcp -d ip.of.box.2 –dport 3306 -j SNAT –to-source ip.of.box.1
Presto! All traffic to “ip.of.box.1” on port 3306 is now being routed out to 3306 on “ip.of.box.2”.