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.
As an update to an older article I once posted, it is now much simpler to enforce a strict password policy on Horde through Plesk.
In 11.5.30 plesk and higher, first make sure you’re current on all microupdates
/usr/local/psa/admin/bin/autoinstaller --select-product-id plesk --select-release-current --reinstall-patch --install-component base
and from there all that is required is to change the “Security Policy” in the Plesk control panel and it will impact Horde’s password functions.
Home> Tools & Settings> Security Policy
Just in case anyone out there is following my old article and noticing that the changes they are making are not being applied, it is because Plesk’s implementation of Horde is now using Plesk’s password policy directly.
I got a request from a client today to redirect port 3306 on his localhost port to an external db server.
I started down my usual road of port redirection with iptables, before I began to realize that I couldn’t successfully DNAT localhost. It’s not a normal interface and doesn’t behave like one. I didn’t have a lot of time to spend on this one or I probably would have dug into iptables further to see if I could figure out a more elegant way to solve the problem (and I may still go back and play around in my own private environments to see if I can), but this is what I came up with that seemed to work a charm.
From the config file:
sh-4.1# cat /etc/xinetd.d/mysql
socket_type = stream
wait = no
user = root
redirect = 192.168.100.100 3306
bind = 127.0.0.1
A quick check that it was binding after an xinetd restart:
sh-4.1# netstat -natp | grep LISTEN | grep 3306
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 30264/xinetd
And after adjusting the users on the db server to permit remote access via the server’s ip address, it was working like a champ.
One note: if you use a user’s my.cnf file to set username and password, you need to modify it to look like:
sh-4.1# cat .my.cnf
protocol = TCP
or via command line parameter:
sh-4.1# mysql -h localhost -u USERNAME -p --protocol=tcp
otherwise it keeps looking for the mysql sock file. What this effectively means for php scripts is that you need to use 127.0,0.1 rather than “localhost”, to force the tcp connection.
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.
Today has been a day for buggy php modules.
I was installing the xhprof module for a client when I got this error back from pecl:
Cannot find config.m4.
Make sure that you run ‘/usr/bin/phpize’ in the top level source directory of the module
ERROR: `phpize’ failed
It didn’t take me terribly long to find the bug report.
Inside of it is the steps to get around the bug:
pecl install --force xhprof
cp -a xhprof-0.9.2/extension/* xhprof-0.9.2/
sed -i -r -e "s%(
tar czf xhprof-0.9.2.tgz package.xml xhprof-0.9.2
pecl install --force xhprof-0.9.2.tgz
Worked like a charm.
Here’s a fun one I’ve not run into in some time:
I was installing the php mailparse extension for a client. Same old, same old. Did the usual pecl install (with a -n flag because the mbstring requirement was installed from RPM and the mailparse pecl installer was not recognizing that). It installed without issue, I made my /etc/php.d/mailparse.ini file and went to check my work with a php -m command. Low and behold…. an error!
PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib64/php/modules/mailparse.so’ – /usr/lib64/php/modules/mailparse.so: undefined symbol: mbfl_name2
I scratched my head a bit, poking around, before I found it. Mailparse requires mbstring but was somehow being loaded before it and, as a result, failing. I renamed my ini file to z_mailparse.ini, to ensure it loads after everything else, and the error cleared.
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;
As almost everyone knows, your linux filesystem sets aside a portion of the free space as “reserved”. This is 5% of the drive space, by default.
[root@pabu ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/disk1 931G 166G 719G 19% /home/disk1
If you do the math there, 166+719= 885GB. That means the file system is reserving 46GB. This 5% reservation made a lot more sense when hard drives were 120MB than when we are looking at TB or higher file systems.
Fortunately, it is fairly easy to change. If I want to modify it to be 2% rather than 5%, I just do:
[root@pabu ~]# tune2fs -m 2 /dev/mapper/disk1
tune2fs 1.41.14 (22-Dec-2010)
Setting reserved blocks percentage to 2% (4883788 blocks)
[root@pabu ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/disk1 931G 166G 747G 19% /home/disk1
Now I am getting 913GB of my drive, rather than 885.
I would caution you to be careful on how you tweak this. I would never set 0%. Ever. However, setting it to 1-2% on drives, depending on what they are doing (and giving consideration for how large a buffer that provides you for when you do eventually fill that drive) will most likely help you recover from a “my file system says it is 100% full but I can see there is still 50GB there!” issues.