Month: July 2004

Unistalling qmailtoaster rpm

rpm -e autorespond-toaster-2.0.2-1.0.7 control-panel-toaster
-0.5-1.0.5 courier-imap-toaster-3.0.3-1.0.6 daemontools-toaster-0.76-1.0.6 ezmlm
-toaster-0.53.324-1.0.9 horde-toaster-2.2.3-1.0.9 isoqlog-toaster-2.1-1.1.5 mail
drop-toaster-1.5.3-1.0.3 maildrop-toaster-1.5.3-1.0.3 qmailadmin-toaster-1.0.6-1
.0.8 qmailmrtg-toaster-3.4-1.0.10 qmail-toaster-1.03-1.0.15 ucspi-tcp-toaster-0.
88-1.0.10 vpopmail-toaster-5.3.8-1.0.12 vqadmin-toaster-2.3.4-1.0.8 ezmlm-cgi-to
aster-0.53.324-1.0.9 courier-imap-toaster-doc-3.0.3-1.0.6 daemontools-toaster-do
c-0.76-1.0.6 ezmlm-toaster-doc-0.53.324-1.0.9 isoqlog-toaster-doc-2.1-1.1.5 mail
drop-toaster-devel-1.5.3-1.0.3 qmail-toaster-doc-1.03-1.0.15 qmail-pop3d-toaster
-1.03-1.0.15 ucspi-tcp-toaster-doc-0.88-1.0.10 vpopmail-toaster-doc-5.3.8-1.0.12
qmail-pop3d-toaster-1.03-1.0.15 mutt-1.4.1-3.4 mdadm-1.5.0-9 qmail-scanner-1.22
-1.2.3 redhat-lsb-1.3-3.centos.0 squirrelmail-1.4.3-0.e3.1

remove db entries in mysql:table(user, db, tableprv)

userdel stuff
rm -rf /home/vpop

rpm -e courier-imap-toaster-debuginfo vqadmin-toaster-debuginfo tnef-toaster maildrop-toaster maildrop-toaster-debuginfo SpamAssassin-toaster-tools ucspi-tcp-toaster-debuginfo autorespond-toaster-debuginfo ezmlm-toaster-debuginfo qmailmrtg-toaster qmailmrtg-toaster-debuginfo clamav-toaster daemontools-toaster-debuginfo clamav-toaster-devel vpopmail-toaster-debuginfo qmailadmin-toaster-debuginfo isoqlog-toaster-debuginfo SpamAssassin-toaster qmail-toaster-debuginfo

PHP directives in Apache 2



php_value include_path /usr/share/php:/usr/share/pear:.
php_admin_flag safe_mode On
php_admin_value open_basedir /usr/share/toaster
php_admin_value safe_mode_allowed_env_vars PHP_
php_admin_value safe_mode_protected_env_vars LD_LIBRARY_PATH
php_admin_value disable_functions include
php_admin_value safe_mode_exec_dir /usr/share/toaster/include

AuthType Basic
AuthName “Qmail Toaster v. 1.0 Admin”
AuthUserFile /usr/share/toaster/include/admin.htpasswd
require valid-user

Repair an RPM database safely

Repair an RPM database safely: “First informally: When a process _is_ so killed [sometimes due to a loss of power crash, sometimes due to a third party helper application dying without cleaning up lock state information in files at exit, sometimes due to an impatient admin], it may also leave some small corruption behind in the RPM ‘SleepyCat’ db based database. Usually the simple
rm -f /var/lib/rpm/__db*
will remove the files which hold lock state information (these files start with that distinctive ‘__’). As these lock state holding files are automatically re-created if missing, this is a safe approach.

It would be safest to clear these locks while still in single user mode; as a system is booting up, it is in single user mode before init can fire off any ‘child’ daemon processes. Checking, we can find:
bash-2.05b$ nl /etc/rc.d/rc.sysinit | grep rpm 556 rm -f /var/lib/rpm/__db* bash-2.05b$
That is, in the boot-scripts, recent Red Hat releases do exactly this (here at line 556 of /etc/rc.d/rc.sysinit). The safest approach which will do this for you, automatically, is to simply verify that a single user mode script indeed will do the cleanup at boot time when no other processes are running, and just reboot. [It is all right; that uptime record you were going for is less important than a clean RPM database — try the reboot method.]

But sometimes there are still problems. If the simply removal of the ‘__*’ files does not clear up the problem, it is also possible that other damage exists, such corrupted linked lists, and is separately present. Proceed carefully — take a backup FIRST, before trying to have rpm repair the database.

It is also _usually_ safe to rebuild these lists, thus:
rpm -vv –rebuilddb”

PHP5 and Zend Engine

: ” With PHP 5, will the Zend Engine be able to handle the low level issues like transaction, security, resource pooling, connection pooling etc? Since these low level issues are considered to be the backbone attributes for developing a enterprise applications, how should the PHP programmer be able to handle these low level issues while developing a enterprise applications in PHP 5?

We are not planning to try and copy application servers, no. Some of the features are just unlikely to happen (e.g., transaction management), some of them may happen in the future (connection/resource pooling), and some of them are just general topics, that are addressed in some ways in app servers, and in different ways in PHP, mostly because PHP and app servers tend to be used in very different ways.

Instead, what we’re going to do is work harder on providing tight integration between PHP and application servers. The JSR with Sun about PHP<->Java connectivity is a big step in that direction.”