cleaner builds and using RPMs instead of custom builds

Chrysalis said:
I consider it inferior to use precompiled because.

1 - It's possible the precompiled stuff will depend on something that doesnt exist on the server. In other words more dependency problems.
2 - It is not possible to customise the binary, whatever options and compile optimisations were used to make the binary you have to stick with.
3 - Multiple versions would be required eg. php can be compiled against mysql5 or mysql5.1 client libraries but not both at the same time.
4 - The user is reliant on whoever makes the rpms to keep up to date and keep to not making mistakes whilst with the customapache script they just edit the version number and download the tarballs.

The only advantage for pre compiled rpms and packages I can think off is time, there is no wait for compiling but because its quicker it doesnt mean it is easier and you lose so much flexibility.
Click to expand...
These are some of the reasons that I have liked the fact that DA has chosen to not only compile the needed software, but also provide a tool to make it easier to customize the compiled software. Now, if custombuild could automatically check for update and send a notification when new updates are available, that would be great! :)
 
jlandes, you can do that now :) Just add this script to cron.daily or anywhere you want:

Code: 
#!/bin/sh
cd /usr/local/directadmin/custombuild
./build update >/dev/null 2>&1
AVAIL_UPDATES="`./build versions | grep -c -e 'update is available.'`"
if [ "${AVAIL_UPDATES}" -gt 0 ]; then
    ./build versions | grep 'update is available.' | mail -s "${AVAIL_UPDATES} updates available for `hostname`" [B][email protected][/B]
fi
exit 0;
 
smtalk said:
jlandes, you can do that now :) Just add this script to cron.daily or anywhere you want:

Code: 
#!/bin/sh
cd /usr/local/directadmin/custombuild
./build update >/dev/null 2>&1
AVAIL_UPDATES="`./build versions | grep -c -e 'update is available.'`"
if [ "${AVAIL_UPDATES}" -gt 0 ]; then
    ./build versions | grep 'update is available.' | mail -s "${AVAIL_UPDATES} updates available for `hostname`" [B][email protected][/B]
fi
exit 0;
Click to expand...

This is definitely helpful and wasn't aware this is available in the custombuild. Of course many of our existing DA setups are customapache based. Which hasn't been the easiest upgrade issues to it and custombuild has had it's config bugs.
 
smtalk said:
jlandes, you can do that now :) Just add this script to cron.daily or anywhere you want:

Code: 
#!/bin/sh
cd /usr/local/directadmin/custombuild
./build update >/dev/null 2>&1
AVAIL_UPDATES="`./build versions | grep -c -e 'update is available.'`"
if [ "${AVAIL_UPDATES}" -gt 0 ]; then
    ./build versions | grep 'update is available.' | mail -s "${AVAIL_UPDATES} updates available for `hostname`" [B][email protected][/B]
fi
exit 0;
Click to expand...

Interesting script Martynas ... wacky output however:

PHP5 (CLI) update is available.(B
Apache update is available.(B
ProFTPD update is available.(B
Automake update is available.(B
Libtool update is available.(B

Any way to clean that up?
 
packages... another advantage

Thought I would bring this up as I forgot to mention this item.

Another advantage of using standard packages instead of custom compiling, at least with Virtuozzo. With VZ by default you are using the same binary that's linked to each VPS instance. With having each custom compiled will equal different binary and with VZ will take up more memory and not be as efficient. Xen and VMWare do not have this advantage since each instance use a separate binary and memory space.

A thread on VZ and Xen differences can be found here:

http://www.webhostingtalk.com/showthread.php?t=694529
 
The impression I got from the thread to which you point is that OpenVZ/Virtuozzo are more efficient. Yet I notice you sell Xen VPS and not OpenVZ/Virtuozzo. Am I reading something wrong?

Is the memory and or disk usage more important than the other issues in the thread to which you point?

I'm very interested in this; I want to start building Virtual Servers.

Thanks.

Jeff
 
jlasman said:
The impression I got from the thread to which you point is that OpenVZ/Virtuozzo are more efficient. Yet I notice you sell Xen VPS and not OpenVZ/Virtuozzo. Am I reading something wrong?
Click to expand...

More efficient with VZ AS long as you use the same binary is the point of my posting. Otherwise you aren't using one of the advantages of VZ. Custom compiling code per VPS you do not get this advantage. With Xen you don't even have this option so it's a mute issue. There is no shared application space.

Actually the thread I pointed you two discusses the advantages/disadvantages of each. IMHO with unfriendly VPSes (meaning unmanaged) VZ overall can have more issues than with Xen. We've had many times Xen instances with 100+ loads, 100% CPU with the other VPSes never even knew the issue existed. With VZ you would not be so lucky. Newer versions of VZ have improved this but only so much.

We do it for many other reasons in addition to this. We don't just offer just one OS distro and plan on rolling out many more in the near future. Something VZ can't really do. Each VPS can have it's own kernel, VZ cannot.

Is the memory and or disk usage more important than the other issues in the thread to which you point?
Click to expand...

With Xen memory and disk is completely fixed there is no chance the provider can oversell these. What you get is what you pay for. There's is no burstable memory, which has it's own issues different than running out of swap space. Xen for the most part appears to be a dedicated server, VZ/Open VZ do not. Odd application issues can occur when burstable memory is not available.

VZ and the providers that offer it really have to oversell to compete with other providers and the pricing model that Parallels offers. There are a few providers that don't oversell, but the major have to. When they don't oversell the pricing becomes similar to Xen. We've figured why even compete on with VZ and just offer Xen when the customers already know overselling isn't an option.

IMHO VZ is one step above chrooting, which is fine for many other providers but not our requirements.

Xen is a perfect middle ground between VMWare and VZ.
 
Last edited:
What would be the best of both worlds is something in the middle.

Why couldn't the build updates be part of the DirectAdmin update system? That is, when we click "Upgrade DirectAdmin" in the GUI, it also runs the build process for updated software.
 
zaphod said:
What would be the best of both worlds is something in the middle.

Why couldn't the build updates be part of the DirectAdmin update system? That is, when we click "Upgrade DirectAdmin" in the GUI, it also runs the build process for updated software.
Click to expand...
I have often thought that would be a good idea as well, even if it is a separate button. :) However, I do like the script that smtalk gave to run a cron job to check for updates.
 
I'll implement a new feature :) Something like "./build cron", it will use an email that is set in the options.conf file.
 
I understand that not everyone would want this, that's obvious. If it was implemented there would need to be an option to turn it off, and also I would think customizable in terms of choosing what you would want automatically built (httpd - no, dovecot - yes, for example). I guess one major problem could be one of permissions though.
 
hostpc.com said:
Interesting script Martynas ... wacky output however:

PHP5 (CLI) update is available.(B
Apache update is available.(B
ProFTPD update is available.(B
Automake update is available.(B
Libtool update is available.(B

Any way to clean that up?
Click to expand...

Update to CustomBuild 1.1.12 (when it will be available on DirectAdmin servers) and set bold=yes in options.conf file :) It will fix this problem.

P.S. CustomBuild 1.1.13 will have an option to send you notifications about the updates.
 
zaphod said:
What would be the best of both worlds is something in the middle.

Why couldn't the build updates be part of the DirectAdmin update system? That is, when we click "Upgrade DirectAdmin" in the GUI, it also runs the build process for updated software.
Click to expand...

Would be far too problematic, the DA update button is for DA itself. The script should remain at the command line.
 
Absolutely.

1) You really don't want to update all your software at any arbitrary time; it could cause downtime. And it could cause some sites to not work.

2) Even though updates generally work without problem, what if there is a problem? If you did it from the control panel you're not going to see any detailed error messages.

3) There are still things you shouldn't do unless you know what you're doing ;).

Jeff
 
You must log in or register to reply here.
Back
Top