If you’d like to run squid on custom port i.e. 8080 with SELinux in enforcing state, be sure to set squid_disable_trans to on – it’s default set to off. Otherwise, squid will not be able to bind to port with “Cannot open HTTP Port” error.
[root@ulisses ~]# getsebool -a | grep squid_disable_trans
squid_disable_trans --> off
[root@ulisses ~]# setsebool -P squid_disable_trans 1
[root@ulisses ~]# getsebool -a | grep squid_disable_trans
squid_disable_trans --> on
If you’re concerned about security you might be interested in simple, but time saving fact, that SquirrelMail seems to require at least fsockopen and popen PHP function to not be disallowed in Apache/mod_php with disable_functions configuration directive. Regards.
Recently I got some trouble with saslauthd unexpectly dying. Despite strong will to discover cause of problems I needed badly some kind of watchdog bringing dead service back to life. Yes, there is still inittab respawn at your disposal, but it has some major drawbacks.
Consider this simple shell script:
#!/bin/sh
# give the $4 service $1 seconds to start
sleep $1
# then every $2 seconds check if it's running by looking
# for $3 string in the list of processes...
# and if it's not running restart the $4 service
while true; do if [[ ! `ps -efw |grep -v grep |grep -v $0 |grep $3|awk '{print $2}'` ]]; then service $4 restart > /dev/null 2>&1;fi;sleep $2;done
It’s expected to run from /etc/rc.local like that:
/usr/local/bin/watchdog 60 60 saslauthd saslauthd&
While trying to receive list of YouTube user’s videos list with Zend Framework 1.0.3 you can get Undefined class constant ‘UPLOADS_URI_SUFFIX’ PHP error. Constant name appear to be incorrectly spelled as UPLAODS_URI_SUFFIX on the 91st line of Zend/Gdata/YouTube.php. It’s easy to fix, this line should look like:
const UPLOADS_URI_SUFFIX = 'uploads';
Later on I found this bug already reported more than month ago:
http://framework.zend.com/issues/browse/ZF-2250
Hope this help, regards.
I’ve recently got trouble transferring files from cd to hard drive. Trying to stay simply – there were filesystem special files with < and > in their names that’ve been causing MS Windows drag & drop copy to fail. Unfortunatelly, these problematic files were placed all around, in every directory of deep directories structure, so it became obvious to me, that sticking to drag & drop with this task will be painfully time consuming. But, there is still some kind of command line at our disposal, so I did it my way:
xcopy <cd_drive_letter>:\* . /C /E
/E switch is the crucial one. Done.
