network_setup problem after upgrade 2.2.3 -> 2.2.14

Greetings!

Since this is my first post here, let me start by expressing my heatfelt gratitude to all the ISPConfig developers. Your creation is pretty much everything I ever dreamed of finding in an open-source hosting controller. Many thanks!

On to my problem: I refer you to the VMware Appliance uploaded by Till (aka "tadorna" on VMware's site), and which can be found at www.vmware.com/vmtn/appliances/directory/342.

First, I updated this appliance to the current state of Debian 3.1 (aka "Sarge"), upgraded the kernel, added the VMware Tools and made some other minor changes to improve clock synchronization between host and guest. All this went without trouble, and if anyone wants the step-by-step description of what was done, I can post it.

At that point, ISPConfig version 2.2.3, which was the one provided in the original upload to VMware's site, seemed to have no problem (in my very limited testing so far). However, I came here looking for newer versions, and found that 2.2.14 was the current one. So I downloaded it to the VM and installed it on top of the old one, as recommended, and as far as I can tell, it went fine (well, at least it signaled successful completion). However, although I have not YET done substantial testing of the upgraded installation, two issues (one minor, one not so minor) became immediately apparent. Here they are:

1) The console boot messages have just ONE slight difference with the boot messages from 2.2.3:

After "Starting ProFTPD ftp daemon:", on the same line, this appears: " - setting default address to 127.0.0.1". I see that this corresponds to a new line being inserted in /etc/proftpd_ispconfig.conf, with the content "DefaultAddress 127.0.0.1". May I presume this is intentional, and not a bug?

2) The network_setup script misbehaves in the following way:

a) the first prompt (language selection) appears normally

b) I answer it (with "en"), I press ENTER, and in very quick sequence the rest of the prompts appear (without line breaks, in one string that wraps around the console display as two lines...), but do not pause to let me type my chosen network settings.

c) The following is then displayed:
IP Address:
Netmask: 0.0.0.0
Gateway:
Network: 0.0.0.0
Broadcast: 255.255.255.255
....
https://:81

I checked the file /etc/network/interfaces, and indeed all the previous values were zapped out, and the last few lines are as follows:

auto eth0
iface eth0 inet static
address
netmask 0.0.0.0
network 0.0.0.0
broadcast 255.255.255.255
gateway

HOWEVER, the command "ifconfig" still displays the previous IP settings, most logically since the values in /etc/network/interfaces are invalid (and the network is still functional).

I located the php script that is called (i.e. /root/ispconfig/scripts/shell/ispconfig_network_setup.php), and looked at it a bit. Mind you, I am NOT a fluent PHP programmer, although I have read up on it a bit. Still, what I see is that the "$fn->getInput()" lines apparently do not wait for a keyboard response. Thus the variables that those getInput() calls are supposed to fill end up remaining empty or null, and those null values are then used in the following "str_replace()" lines that are meant to update /etc/network/interfaces. However, the $interfaces_action command ("/etc/init.d/networking restart") fails to change anything, and if its standard output were not redirected to /dev/null, we would see the following:

Setting up IP spoofing protection: rp_filter.
Reconfiguring network interfaces.../etc/network/interfaces:11: option with empty value
ifdown: couldn't read interfaces file "/etc/network/interfaces"
/etc/network/interfaces:11: option with empty value
ifup: couldn't read interfaces file "/etc/network/interfaces"
done.

Thus the system is left in a state where everything still works normally, but the network WILL fail to start on the NEXT boot (unless /etc/network/interfaces is manually corrected before shutdown or reboot).

Would anyone have an idea of the cause of that bug (and its solution)?

Thanks in advance,

_ renald _
. \_____/

 

Well, I only wished it had been that simple. I would have been quite content to blush and look embarrassed for having neglected such a possibility, with which I am quite familiar (being a very enthusiastic VMware user for the past 4 or 5 years...). Unfortunately, it appears the explanation is not that simple, as I get the same result when I run network_setup through SSH.

Here is the situation before I run the script:

======= 'ifconfig' BEFORE =========

eth0 Link encap:Ethernet HWaddr 00:0C:29:EB:5C:F2
inet addr:192.168.123.136 Bcast:192.168.123.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:feeb:5cf2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:591 errors:0 dropped:0 overruns:0 frame:0
TX packets:451 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:185884 (181.5 KiB) TX bytes:40672 (39.7 KiB)
Interrupt:177 Base address:0x1400

lo Link encap:Local Loopback
(Omitting the rest of the loopback interface)

=== /etc/network/interfaces BEFORE ===

# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo
iface lo inet loopback

# The first network card - this entry was created during the Debian installation
# (network, broadcast and gateway are optional)
auto eth0
iface eth0 inet static
address 192.168.123.136
netmask 255.255.255.0
network 192.168.123.0
broadcast 192.168.123.255
gateway 192.168.123.64
========= END =========

And here is the actual running of the script:

======= BEGIN =========
host1:/etc/network# network_setup
Please select your language [de/en] / Bitte wählen Sie Ihre Sprache aus [de/en]: en
Please enter your desired IP address (e.g. 192.168.0.100): Please enter your netmask (e.g. 255.255.255.0): Please enter your gateway (e.g. 192.168.0.1):
IP Address:
Netmask: 0.0.0.0
Gateway:
Network: 0.0.0.0
Broadcast Address: 255.255.255.255

The network configuration is going to be changed now.
Please wait a moment.
Afterwards you can access the ISPConfig administration interface in your browser under

https://:81
========= END =========

And finally, here is the situation after running the script:

======= 'ifconfig' AFTER =========
eth0 Link encap:Ethernet HWaddr 00:0C:29:EB:5C:F2
inet addr:192.168.123.136 Bcast:192.168.123.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:feeb:5cf2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1237 errors:0 dropped:0 overruns:0 frame:0
TX packets:534 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:335454 (327.5 KiB) TX bytes:51772 (50.5 KiB)
Interrupt:177 Base address:0x1400

lo Link encap:Local Loopback
(Omitting the rest of the loopback interface)

=== /etc/network/interfaces AFTER ===
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo
iface lo inet loopback

# The first network card - this entry was created during the Debian installation
# (network, broadcast and gateway are optional)
auto eth0
iface eth0 inet static
address
netmask 0.0.0.0
network 0.0.0.0
broadcast 255.255.255.255
gateway
========= END =========

So as you can see, it's not just the odd VMware console behavior at play here, since it happens just the same via SSH (from a Windows desktop using Putty-SSH).

Going to bed now (it's 04h32 here....). I'll be back later.

Thanks for responding!

 

A small precision about my request...

Till (and every other reader of this thread),

I just want you to know that my original post was mostly intended to see if anyone else had already encountered this same strange behavior, and possibly had a quick solution that did not require too much research. I have the strong impression that this bug is caused by an uninitialized variable (or array) in the PHP code, but not being fluent enough in that language, I was hoping someone else had found and corrected it some time ago...

Honestly, I have decided to change my strategy for adopting ISPConfig, and build my own ISPConfig Virtual Appliance from scratch (or download a recent one from your site, since I signed up as a paid member).

That old Debian 'sarge' VM with ISPConfig 2.2.3 just happened, entirely accidentally, to be the path to my discovery of ISPConfig, HowtoForge and projektfarm. Naturally, since there was a fairly active thread about it in the VMware forums, I jumped in and tried my best to figure out how to best put that VM to use. And as far as getting the operating system ('sarge') updated with the latest security patches, this went well, and the old ISPConfig 2.2.3 appeared unaffected by these updates.

On the other hand, now that Debian 4.0 ('etch') is the current 'stable', and that Ubuntu also has more recent stable editions (including one with "Long-Term Support"), I think my efforts are best invested in putting together an up to date VM with a recent OS and the latest stable version of ISPCOnfig. So unless someone joins this thread with a quick solution to my issue, I suggest you don't worry too much about it.

One last quick question: once I do have my own Debian+ISPConfig Virtual Appliance up and running, is it ok for me to upload it to the VMware site? Or do you prefer to reserve that right for yourself and your fellow developers?

Regards,

renald

 

same to me ... :-(

i have the same problem with my installation - also the one downloaded from vmware.com.
after i start the script, it only asks me for the first value (language) and then it runs till the end without accepting any further values from me ...
since i also have trouble with some sites which do not appear in the dns-records-manager section, i also think of reinstalling it on a vmware which is up to date - or did someone find a solution for this in the meanwhile?
greetings - ralf

 

i have the same problem with my installation - also the one downloaded from vmware.com.
after i start the script, it only asks me for the first value (language) and then it runs till the end without accepting any further values from me ...
renald - did you put it on any actual release of any linux???
since i also have trouble with some sites which do not appear in the dns-records-manager section, i also think of reinstalling it on a vmware which is up to date - or did someone find a solution for this in the meanwhile?
greetings - ralf