[BlueOnyx:10726] Re: Error in behavior of vHost aliases
Hi William.
On 6/4/2012 12:44 PM, William Thackrey wrote:
If we enter a new web alias or change the web alias in the BlueOnyx Virtual
Site::Services::Web page, the vHost file (i.e site1) in /etc/httpd/conf/vhosts is written
correctly. However, if we clear the Web Server Aliases field, the vSite file does not
get re-writen to reflect the change. That is, a null entry in the field
should clear the aliases in the vHost file. It does not. The previous entries remain.
Deleting or renaming the vHost file causes it to be written correctly.
I replicated what you were doing. In the log file, 99% of the logs are
identical... There are some differences when you add an alias compared
to deleting an alias.
*Add an alias*
Jun 5 06:57:00 node2 cced(smd)[x]: client 6:[y]: SET 98 webAliases
= x.com webAliasRedirects = 1
Jun 5 06:57:00 node2 cced(smd)[x]: client
6:handlers/base/vsite/change_net_info.pl: SET 104 fqdn =
www2.compassnetworks.com.au webAliases = x.com ipaddr =
203.26.211.122
Jun 5 06:57:00 node2 cced(smd)[x]: client
6:handlers/base/vsite/change_net_info.pl: SET succeeded
*Clear alias*
Jun 5 06:57:00 node2 cced(smd)[x]: client 6:[y]: SET 98 webAliases
= webAliasRedirects = 1
change_net_info.pl is the trigger to update the alias file for a vsite.
The line below is from this file:
*_change_net_info.pl_: if ($vsite_new-{ipaddr} || $vsite_new-{fqdn} ||
$vsite_new-{webAliases})*
This IF statement appears to be our smoking smoking gun. What is this IF
statement actually doing? $vsite_new is an object that contains only
CHANGED fields. If we change an IP address, the new address will be in
$vsite_new-{ipaddr}. If this field is not changed, that will be empty.
Same goes for FQDN. Both of those fields are mandatory, so they will
never be empty. However, webAliases is optional. When we clear that
field, it will be an empty value. This if statement thinks nothing has
changed requiring an update to the alias file whenever we clear the alias.
*Solution:*
I had a look at the triggers for this handler. There are three variables
in the associated conf file.
/# handle configuration of various things
Vsite.fqdn perl:base/vsite/change_net_info.pl CONFIGURE
Vsite.ipaddrperl:base/vsite/change_net_info.pl CONFIGURE
Vsite.webAliasesperl:base/vsite/change_net_info.pl
CONFIGURE
/
If the handler is only triggered whenever we update fqdn, ipaddr, or
webAliases we can just comment out that if statement totally...
because one of those things will change each and every time that handler
runs. I've tested this on my box and it looks good to me.
Michael... Are you happy with that fix? The only issue would be if we
add other triggers to that handler in future other than the three above.
Regards,
Greg.
___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:10727] proftp problems - FIXED?
Hi Team.
I've been looking at the proftpd problems that have been recently
reported, and I have some good news. I've tested, and I believe I have a
fix. This is actually I think a bug that has been around for a very long
time back to the BlueQuartz days. The weird thing is that this problem
was not happening uniformly on all servers and it used to come and
go after different updates.
Here's what I found in the log files
Jun 5 10:00:01 node1 xinetd[24021]: START: ftp pid=3620 from=127.0.0.1
Jun 5 10:00:01 node1 proftpd[3620]: warning: ProFTPD address/port
(203.26.211.121:21) already in use by ProFTPD server
Jun 5 10:00:01 node1 xinetd[24021]: EXIT: ftp signal=11 pid=3620
duration=0(sec)
Before testing, I validated that nothing was using port 21 except for
xinetd. If I retry another FTP straight after the initial failure, it
works perfectly.
I did some digging, and found a command line option in the proftpd man
page that looked interesting...
-N,--nocollision
Disables address/port collision checking.
I threw this into /etc/xinetd.d/proftpd and everything started working.
Below is a copy of my file...
I would appreciate it if a few of you could test this to verify it is
indeed the smoking gun!
Regards,
Greg.
===
# default: off
# $Id: proftpd-xinetd,v 1.2 2002/06/10 15:35:47 dude Exp $
# description: The ProFTPD FTP server serves FTP connections. It uses \
# normal, unencrypted usernames and passwords for authentication.
service ftp
{
socket_type = stream
wait= no
user= root
server = /usr/sbin/in.proftpd
server_args = --nocollision
log_on_success += DURATION
log_on_failure += USERID
nice= 10
disable = no
instances = 80
}
___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:10728] Re: Error in behavior of vHost aliases
Hi Greg, If the handler is only triggered whenever we update fqdn, ipaddr, or webAliases we can just comment out that if statement totally... because one of those things will change each and every time that handler runs. I've tested this on my box and it looks good to me. Michael... Are you happy with that fix? The only issue would be if we add other triggers to that handler in future other than the three above. Hmm ... if that works, then yeah: Let's do it that way. -- With best regards Michael Stauber ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:10729] Re: Kickstart error during install of BlueOnyx 5108R
Michael, Did you want me to edit files in the ISO and reburn it? I'm not sure where you want me to edit these files. This is a new install I am attempting. If you needed remote access to this machine in rescue mode I can set that up for you. Herb - Original Message - From: Michael Stauber mstau...@blueonyx.it To: BlueOnyx General Mailing List blueonyx@mail.blueonyx.it Sent: Monday, June 4, 2012 7:59:18 PM Subject: [BlueOnyx:10725] Re: Kickstart error during install of BlueOnyx 5108R Hi Herb, I finally had a chance to boot into rescue mode. It did activate the network with the built in Broadcom NetXtreme 5709 Dual Port Gigabit Ethernet NIC as em1 instead of eth0. What can I do about this to get it to install on this dell server? Please try this, as I would be interested to know if it works: 1.) Edit /lib/udev/rules.d/71-biosdevname.rules and commend out the Dell whitelist line. 2.) Remove /etc/udev/rules.d/70-persistent-net.rules and /etc/udev/rules.d/90*.rules if they exist. 3.) Edit /boot/grub/grub.conf The Kernel lines in it look a bit like this: kernel /vmlinuz-2.6.18-308.4.1.el5 ro root=/dev/VolGroup00/root noapic At the end of your kernel line(s) put this: biosdevname=0 So taking the above example it would look like this: kernel /vmlinuz-2.6.18-308.4.1.el5 ro root=/dev/VolGroup00/root noapic biosdevname=0 The biosdevname line got wrapped by my email client. It goes into the same line as kernel /vmlinuz 4.) Reboot and see what it does. Also check ls /sys/class/net, ifconfig -a and dmesg after the reboot to see what they report about the network interfaces. All in all this is a bit frustrating. I do not have a Dell for testing and I already tried to walk someone who had a similar problem with a Dell 710 through doing this. We tried various approaches and the above one *should* possibly work, but it didn't. -- With best regards Michael Stauber ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx -- Herb Rubin Pathfinders Software http://www.pfinders.com ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:10730] IPv6
Is BlueOnyx ready or ready for migration? IPv6 kick off is June 7 2012 -- +-+ Richard C. Barker Sr. ProBass Networks Inc. +-+ ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:10731] Re: proftp problems - FIXED?
This looks like the issue I am having consistantly on one server - I will
give it a shot tomorrow morning and see if it fixes it and let you know.
Bill Hicks
Hi Team.
I've been looking at the proftpd problems that have been recently
reported, and I have some good news. I've tested, and I believe I have a
fix. This is actually I think a bug that has been around for a very long
time back to the BlueQuartz days. The weird thing is that this problem
was not happening uniformly on all servers and it used to come and
go after different updates.
Here's what I found in the log files
Jun 5 10:00:01 node1 xinetd[24021]: START: ftp pid=3620 from=127.0.0.1
Jun 5 10:00:01 node1 proftpd[3620]: warning: ProFTPD address/port
(203.26.211.121:21) already in use by ProFTPD server
Jun 5 10:00:01 node1 xinetd[24021]: EXIT: ftp signal=11 pid=3620
duration=0(sec)
Before testing, I validated that nothing was using port 21 except for
xinetd. If I retry another FTP straight after the initial failure, it
works perfectly.
I did some digging, and found a command line option in the proftpd man
page that looked interesting...
-N,--nocollision
Disables address/port collision checking.
I threw this into /etc/xinetd.d/proftpd and everything started working.
Below is a copy of my file...
I would appreciate it if a few of you could test this to verify it is
indeed the smoking gun!
Regards,
Greg.
===
# default: off
# $Id: proftpd-xinetd,v 1.2 2002/06/10 15:35:47 dude Exp $
# description: The ProFTPD FTP server serves FTP connections. It uses \
# normal, unencrypted usernames and passwords for authentication.
service ftp
{
socket_type = stream
wait= no
user= root
server = /usr/sbin/in.proftpd
server_args = --nocollision
log_on_success += DURATION
log_on_failure += USERID
nice= 10
disable = no
instances = 80
}
___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
