It can be very frustrating waiting for changes to DNS to propagate across the net. There is little that can be done to actually speed up this process except for this little trick I picked up. Even when propagation has completed, your PC can refuse to see the new IP because it is cached in the DNS Resolver Cache on your PC.
The solution is to flush the DNS Resolver Cache using ipconfig. Open a command console on your PC ( Run as Administrator if using Vista ).
Then execute this command …
ipconfig /flushdns
Hope this helps someone
If you are looking for ways to lock-down your ProFTPD server without using iptables this may help. I recently had to find a way of securing a VPS without iptables. The ftp server only needed to be accessed by a few known users so I ended up with two reasonable possibilities.
- Switch ftp on and off manually as and when it was needed (most secure)
- Configure ProFTPd to only allow connections from specific IP’s
I opted for the last choice. To configure this you need to modify the /etc/proftpd.conf file by adding a
<Global>
AllowOverwrite yes
<Limit ALL SITE_CHMOD>
AllowAll
</Limit><LIMIT LOGIN>
Order Allow,Deny
Allow from xxx.xxx.xxx.xxx (IP’s to allow)
Deny from all
</LIMIT></Global>
Hope this helps someone!
I had to track down this problem when I found that my cgi scripts were failing with a 500 Server Error.
The problem is with SUExec which normall requires the cgi scripts to be in the document root.
The fix is to recompile the SUExec with the document root set to /home. Follow these instructions …
- download the Apache source for your version of apache
- compile suexec with these commands :
# ./configure –with-suexec –with-suexec-docroot=/ –with-suexec-logfile=/var/log/suexec.log –with suexec-caller=nobody
# make suexec - Backup the old version of suexec and replace with your new version
- reboot
Hope this helps someone!
To change file permissions to 644 use …
# find . -type f -exec chmod 644 {} \;
To change file permissions to 755 use …
# find . -type d -exec chmod 775 {} \;
QmailToaster is a quick and easy way to install QMail on your server. However when things go wrong there are a few files and techniques you need to know about to track problems down. this post is a simple way for me to document some of the most useful bits of information. Hopefully they will help someone.
My system is Fedora 6, different systems may have slightly different locations.
First step is to examine the SMTP log…
# cat /var/log/qmail/smtp/current | more
If you just want to monitor the log in real time, login as admin, note the use of tai64nlocal that converts the timestamps into a readable format …
tail -f /var/log/qmail/smtp/current | tai64nlocal
Incoming SMTP traffic is handled by:
/var/qmail/supervise/smtp/run
This script runs the qmail-smtp service against the incoming email. The script receives various environment variables set up by rules in the tcp.smtp file. For changes in the tcp.smtp file to take effect you need to rebuild the cdb files …
qmailctl cdb
These files and programs are a great place to start when tracking down a qmail problem
Every now and then I have needed to delete a whole directory tree. This is the correct command BUT TAKE WARNING! It will delete the whole directory tree without warning, ALL sub directories and files- so make sure you get it right or you can cause SERIOUS damage to your installation.
rm -rf folder_name
Lots of apps are now looking for php 5.2 to run but Fedora 6 currently only updates to 5.1 in the repositories. The update does not appear straight-forward, however after much googling I found a solution that worked for me here . Simply follow these steps … You need to login using ssl ( then su for admin ) or similar console …
# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
# rpm -Uvh http://rpms.famillecollet.com/el5.i386/remi-release-5-4.el5.remi.noarch.rpm
# yum –enablerepo=remi update php
Later I needed to add the mcrypt extension also …
# yum –enablerepo=remi install php-mcrypt
Moving across from php4 to php5 has generally not been to problematic. So it is ironic that the one thing that has been a problem is Zend Studio - produced by the “Php People”. I develop on an XP machine, using apache 2.2. php 5.2 and zend studio 5.1 Standard addition.
Unlike php4, php5 does not have the mysql module in the core and it needs to be enabled in php.ini. No problem, simply add extension = php_mysql.dll to the php.ini file. Everything works perfectly on my system EXCEPT when I try to debug using Zend Studio, where I get a dialog stating …
PHP Startup: mysql: Unable to initialize module
Module compiled with module API=20060613,debug=0,thread-safety=1
PHP compiled with module API=20050922, debug=0, thread-safety=1
These options need to match.
Much searching and Googling did not provide an answer. To me it appears that the internal php used by Zend Studio is not compatible with the latest php5 version. Going back to an older version of php might work but is not a practical solution for me; Making the Zend Studio software virtually useless unless Zend can help
Time to raise a ticket with Zend and see what they have to say … I’ll let you know as soon as they come back to me… meanwhile if you have a fix to this… please share !
This had me baffled for awhile. No matter what I did, wrapped it in divs or a table, Firefox would always leave a small space below the image. Finally discovered that this is a bug in my current version of Firefox 2. Very frustrating because everything worked perfectly in IE.
The workaround is to change the DOCTYPE to something other than STRICT.
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>
Hope this helps someone!
The process of upgrading PHP on my windows XP system proved to be a painful one, the following error in particular proved difficult to fix or find helpful information on .
PHP Startup: Unable to load Dynamic Library php_openssl.dll The operating sytem cannot run %1
This issue is I believe caused by a mismatch of dll versions. php_openssl.dll is dependant on two other dll’s ssleay32.dll and libeay32.dll . Both these dll’s should be in your default php directory.
The problem however for me was that there was a very much older version of these dlls in the WINDOWS/system32 directory and I believe that somehow these were getting picked up before the ones in the php directory.
Answer: Backup the old ssleay32.dll and libeay32.dll from the system32 directory and then copy in the newer versions from your php directory. I had some problems copying the files because they were locked by a service and windows would not permit them to be copied over.
Answer: You may not get this problem, but if you do, simply rename the dlls to something like ssleay32.dll.old and libeay32.dll.old and then copy the files in ( I rebooted but you probably don’t need to).
When I rebooted, the problem was fixed but of course the rogue application that had dumped this old dll into the system32 directory in the first place choked ( unable to find ordinal number in ssleay32.dll ). This turned out to be my Belkin Wireless Monitor program. I will probably remove this software but the quick fix was to copy the old dll’s which I had backed up into the belkin monitor application directory.
This solution will probably work for other php dll’s that show similar errors. Find what the dll’s dependencies are, check for other versions of these on the system and then apply the same process using the appropriate dlls.
WARNING — ALWAYS backup the dlls you intend to change from your system directories, if things get messed up they will be your only way back.