1.337

Zomg!
My clients call me every minute and ask: "When?"
What should i tell them?
Wait for fix freaking freebsd cpuinfo bug?
 
What are your clients experiencing? Are you sure its related to the bug?
 
Look at screenshot,

At start i see:
1.gif


HTML code:
....
<img border="0" src="IMG_SKIN_CTRL_AFEATURES" width="500" height="68">
<table border="0" width="100%" cellspacing="0" cellpadding="3">
<tr>
<td width="50%" valign="top" class="left-pad">
<a href="/CMD_ADMIN_STATS">Complete Usage Statistics</a><br>
<a href="/CMD_CUSTOM_HTTPD">Custom HTTPD Configurations</a><br>
<a href="CMD_PHP_SAFE_MODE">PHP SafeMode Configuration
^^^^^^^^^^^^^^^^
Nothing after.

After 10-20 seconds waiting i see:
2.gif


I happens at every page.

My /var/log/directadmin/error.log is:
2009:05:28-17:36:46: Socket write error: fd is connected to a pipe or socket whose reading end is closed. When this happens the writing process will also receive a SIG_PIPE signal. (Thus, the write return value is seen only if the program catches, blocks or ignores this signal.)
2009:05:28-17:36:48: Socket write error: fd is connected to a pipe or socket whose reading end is closed. When this happens the writing process will also receive a SIG_PIPE signal. (Thus, the write return value is seen only if the program catches, blocks or ignores this signal.)
2009:05:28-17:37:41: Socket write error: fd is connected to a pipe or socket whose reading end is closed. When this happens the writing process will also receive a SIG_PIPE signal. (Thus, the write return value is seen only if the program catches, blocks or ignores this signal.)

My system is:
# uname -a
Linux host.tld 2.4.20-8smp #1 SMP Thu Mar 13 17:45:54 EST 2003 i686 i686 i386 GNU/Linux
Redhat 9
 
Last edited:
In any case your system is so old I could step on his beard from here. Upgrade it unless you want any cracker around the world to penetrate it.
I'm sure the problem will solve itself as soon as you upgrade at least your kernel and glibc, there is no need to wait for the DA 1.33.7 release.
 
I also think that the bugfix may solve your problem, but that's not what I'm talking about. Your server has obsolete and vulnerable software running, which has nothing to do with the rule "if it isn't broken don't fix it". Your server must be fixed, because its security is like a swiss cheese: full of holes.

If you want (and with a written and signed contract) I can try to crack it and send you the content of your /etc/shadow file... I'm pretty sure it wouldn't take more than a few minutes.
 
So i need that fix.
Click to expand...

No you need your operating system fixed. I recommend you immediately take it offline and upgrade the operating system. Your problem is so serious it goes beyond simply upgrading DirectAdmin. Running RedHat 9 at this point is simply irresponsible unless you are some kind of security expert and upgrade everything manually which obviously you don't because you have not even updated the kernel. 2.4.20 was released November 28, 2002.
 
Hello,

Firstly, the index.raw fix is simply an optimization for some systems that don't cache data to be sent in larger chunks for plugins that actually use this feature.

This:
http://www.directadmin.com/features.php?id=972

*only* applies to plugins:
/CMD_PLUGINS

commands where the file extension is .raw.
Stock DA skins do not use the raw extensions, as DA doesnt include any plugins by default.

So, by the right side of your page not showing up, if the .raw optimization is what you're looking for, then it implies that both:
1) you've got a custom skin
2) with a plugin embedded on the right column.

If in fact that is the case for you, you'll be pleased to note that the current binaries distributed were updated with that fix prior to 1.33.7 being released. IE: they're avaiable now.
To ge them now, you'd use this:
http://help.directadmin.com/item.php?id=29
They're still 1.33.6, but just with that 1 change added to them.

*However*

If you're not using a custom skin, and the right column is php related, then the id=972 change is not related to you in any way. My guess is that it might be a php slowdown somewhere, in which case, check /usr/local/bin/php and try sending data to it, eg:
Code: 
echo '<? echo "hi\n";?>' | /usr/local/bin/php
to see what that returns, and how fast.

John
 
interfasys said:
This should be
Code: 
echo '<?php echo "hi\n";?>' | /usr/local/bin/php
;)
Click to expand...

Same thing unless you have short_open_tag turned off in php.ini. Its on by default.

Code: 
[root@server ~]# echo '<? echo "hi\n";?>' | /usr/local/bin/php
hi
[root@server ~]# echo '<?php echo "hi\n";?>' | /usr/local/bin/php
hi
 
Same thing unless you have short_open_tag turned off in php.ini. Its on by default.
Click to expand...
It's been turned off since 5.3 in some packages and I thought it was deprecated, but after having checked, it seems the PHP devs still don't know themselves.

Imho, it's safer to stick to strict coding.
 
That may be true. What I mean by default is its the default setup when DirectAdmin is installed. I just did a new setup a few weeks ago and that is how it was set up.

I know I am not going to be responsible for breaking somebody's code by changing now.
 
That is one thing I have never understood about DirectAdmin. If the DirectAdmin team wanted to be responsible they would remove the operating systems that no longer provide security updates from the list of "supported" operating systems page (http://www.directadmin.com/install.html). It is extremely irresponsible to claim the things like Redhat 7.2 are supported when we know for a fact that 7.2 is vulnerable to many exploits. Directadmin may run on Redhat 7.2 but it should not be run on 7.2! Same is the case with Redhat 9 above, all fedora versions, etc...


my 2 cents.
 
What does this have to do with this thread?
 
Last edited:
You must log in or register to reply here.
Back
Top