Discussion about CustomBuild

Already tried it and succeeded ...

Cees.

cpisuisse said:
Our client asked us to install pear HTML_Template_IT.
I am wondering whether the procedure should be:

# pear install HTML_Template_IT

And then ./build php n

Or is there a way to do this with custombuild entirely.

Server is Centos 5 64Bit
Click to expand...
 
webbird said:
Hello,

I have a problem installing mod_cache with custom build.
I've tried all steps from this guide
http://help.directadmin.com/item.php?id=191

No errors with
./build clean
./build apache

My configure.apache is ok with these lines
"--enable-cache" \
"--enable-mem-cache" \
"--enable-disk-cache" \
"--enable-file-cache"

I've added mod_cache in httpd.conf

But after all I can't locate mod_cache in /usr/lib/apache
:confused:
Click to expand...

Same problem here. How tha hell do i enable mod_cache?
 
Hello,

If you've compiled it right into the httpd binary, then it's not going to be a ".so" file in /usr/lib/apache. It will be right in the binary, no external files. To check:
Code: 
/usr/sbin/httpd -l
John
 
CLI to CGI

Hi
I have a dedicated server from a host company (we shall leave the name out for now)
Basically on configuration of the server they set it to CLI
This was back in February of this year and I have had nothing but issues since
I have direct admin installed and have 6 domains at the user level all assigned to different packages
All of these sites are set up using Joomla 1.5
The first issue was that upon installation of Joomla all files become unwriteable. The only way i found around this was to advise people to set their public_html to 777 which is not advisable and then set it back after the changes are made.
I have been in contact with the hosting company several times about this and got nowhere.
Two days ago a client contacted me to say that they were trying to FTP a file to the server and got operation not permitted. As this was a file and not a module then the back end joomla install wasnt to be used.
I looked myself and found that on all the domains it is the same.
After raising a ticket a world of pain has followed
To cut a long story short all of the files were been owned by apache as the server was set to CLI. After reading some direct admin forum posts of which the hosting company was also they set it to CGI instead which should move all permissions to the user and not apache.
Since then people can add, edit alter any new items but cannot change any existing items that were on the server
ALL php files are unwriteable on every domain
I am assuming the hosting company did the step to change it to CGI but forgot about some script? to change existing file / folder / php permissions
Any advice would be greatly appreciated as I have had 72 responses from the hosting company and they are not getting any nearer to solving the issue

Thanks in advance

Stanster
 
I should only suggest to tell your hosting provider to use php cli and mod_ruid2 for apache so all file will be owned by user and not 777 directory will be needed.

Actually, as far as i know, you cant do nothing for change file ownership.. so, just your hosting provider have to find a solution, or, change ownership anytime is needed.

Regards
 
I'm still using CLI with mod_security2.

I'd like to ask a few questions about ruid2. People say its secure, but I'm trying to understand whats so different about 777 and this? Even with no 777, scripts can be saved/written to all directories within that user's home directory with any permission - so if a script has an exploit, how does ruid2 combat this?

I still see people getting shell hacked even when they're using suphp or ruid2.

If my analogy is wrong, please correct me.
 
Well this is just my opinion and im not totally sure.

But i think that major problem of 777 permission is that ownership of file will be apache, so, have more privileges on system than a single user that is related just to his home directory.

If im wrong, feel free to correct me

Regards
 
That, and the same reasons to choose to use suPHP. Then you can ask suPHP vs mod_ruid2, and mod_ruid2 seems to win this battle.

Also see http://www.directadmin.com/forum/showthread.php?t=37467#7

And yes, if a website gets compromised mod_ruid2 won't stop the trouble it causes that website, or account, but it will probably saves other users trouble, if they dont use chmods like 777.

With normal apache:
Script runs under apache under user x and can access a directory chmodded 777 of user y.

mod_ruid2:
Script runs under user x, user y doesn't have a directory chmodded 777 because that isn't required, so it can't access it.

Of course theres open_basedir and other things, but this is the general idea I think. But as the other 2 posters above me, correct me if Im wrong.
 
Peter Laws said:
I'm still using CLI with mod_security2.

I'd like to ask a few questions about ruid2. People say its secure, but I'm trying to understand whats so different about 777 and this? Even with no 777, scripts can be saved/written to all directories within that user's home directory with any permission - so if a script has an exploit, how does ruid2 combat this?

I still see people getting shell hacked even when they're using suphp or ruid2.

If my analogy is wrong, please correct me.
Click to expand...

I was looking at ruid2 because of this thread and there was this caution that if httpd is compromised, ruid2 would then give the hacker the ability to effectively become root. That kind of set off alarm bells and I'd rather live with apologizing and restoring user files from daily backups, then to have to wipe and re-install a potentially root compromised server.
 
emmanuel said:
I was looking at ruid2 because of this thread and there was this caution that if httpd is compromised, ruid2 would then give the hacker the ability to effectively become root. That kind of set off alarm bells and I'd rather live with apologizing and restoring user files from daily backups, then to have to wipe and re-install a potentially root compromised server.
Click to expand...

I agree. That is why I am using suphp instead, because I am a little worried that mod_ruid is not equally safe compared to suphp.
 
Peter Laws said:
Now I'm confused, you say suphp is better than ruid2, even though suphp uses more resources? :confused:
Click to expand...

ditto/emmanuel are talking about security, not resources.

There seems to be the risk that the whole uid swapping story ruid uses, also creates the extra risk of swapping it to root (in the event of httpd is exploitable) again see this topic http://www.directadmin.com/forum/showthread.php?t=37467#7

I've got a grsecurity patched kernel which *should* protect me against it, together with the benefits, and small risks I feel safe using mod_ruid2.

--

I've also searched about it on the web and found the following:

old thread about mod_ruid(1)

posix_setuid(0);

# Crash the system through L1nux's "killing processes makes them
die" vulnerability!
posix_kill(1, SIGKILL);
Click to expand...

I've tested this:

PHP: 
<?php
echo posix_getuid()."<br>\n";
echo posix_geteuid()."<br>\n";
posix_setuid(104); // or any other uid
echo posix_getuid()."<br>\n";
echo posix_geteuid()."<br>\n";
?>

All keep the same uid, so this doesn't work.

They talk about it (again the old version) on the dutch webhostingtalk having more tests.

I've tested it, putting the compiled test.cc in /cgi-bin/ trying to set the uid to 0 ( setuid(0); ), and it fails: the same uid remains.

Another test in the same thread using scripts on http://www3.servertje.net/ruid/

Also put it to the test. You create a .so module to load it in php. This one actually does set the uid to root, if you have the compiled .so (could be compiled remote, uploaded), but you would also need the php function dl(); and enable_dl = 1;

But of course you have this disabled in php.ini. I've also added --disable-posix in the php build paramters just to be sure on the posix functions.

If anyone else has more info, please share. What I also wonder is if it would be possible to prevent posix uid swappings to root just to tackle it all together.
 
I have a question about the Custombuild.
Can someone tell me the difference between ./build update and ./build update_data?
 
update_data doesnt update the build script only the data files. I never personally used update_data.
 
That's clear. For now i've a last question. :)

However, talked about clear.. Can anyone tell me when it's usefull to run ./build clear?

Anyone an idea?
 
Last edited:
If you have "clean=yes" set in the options.conf file, it calls the function every time you run the CustomBuild script.
 
Custombuild

Hello,

if I type ./build update or whatever, it works perfectly.. but once it finish, I should manually change aliases and paths for: roundcube, phpmyadmin and sqmail..

I love extra security, that's why I never use standart parts for web abbs such as: phpmyadmin, sqmail, roundcube, webstats etc..

Is there way to make it standart?

Thx!
 
I doubt that /etc/httpd/conf/extra/httpd-alias.conf is ever touched on update with custombuild. So edit the file to fit your needs.
 
zEitEr said:
I doubt that /etc/httpd/conf/extra/httpd-alias.conf is ever touched on update with custombuild. So edit the file to fit your needs.
Click to expand...

yes, I've already did that.. the problem is, once I update softwares such as phpmyadmin, roundcube etc.. via build update command, it install it under /var/www/html folder.. thats ok but it put there 2 directories etc.. bv:
roundube > roundube_0_6
rounducbe_0_6

everything I must manually remove the first folder, change the second foldername to another name..
 
You must log in or register to reply here.
Back
Top