virtualmin-base_1.0-13_all.deb weirdness

17 posts / 0 new
Last post
#1 Tue, 02/19/2008 - 00:12
jezdez

virtualmin-base_1.0-13_all.deb weirdness

I'm a Virtualmin Pro customer.

After running "aptitude update && aptitude dist-upgrade" I was presented a new version of the package virtualmin-base. Which I upgraded of course.

It then ran the whole virtualmin setup process again and while "Configuring firewall rules" it cut me off the server. I needed to restart the whole server to fix this!

Tell me that the package wasn't supposed to be installed, please. I'm running shorewall as a firewall here, do you think this collided somehow with the postinst script?

Cheers

Tue, 02/19/2008 - 00:42
webinger

Hi jezdez

I use ipchains. It deleted my Teamspeak Ports, but the rest was still instact.
But it changed my postfix config.
mailbox_size_limit is smaller than message_size_limit

mailbox_size_limit = 2147483648
message_size_limit = 20240000

i never set the mailbox size limit.

But i also don't understand the error as the mailbox size limit is bigger than the message size limit ;)

it also changed my smtpd recipient restrictions from:

smtpd_recipient_restrictions =
permit_sasl_authenticated,
reject_non_fqdn_sender,
permit_mynetworks,
reject_invalid_hostname,
reject_unauth_destination,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
####reject_unlisted_recipient,
reject_non_fqdn_recipient,
####reject_unknown_sender_domain,
reject_rbl_client ix.dnsbl.manitu.net,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client list.dsbl.org,
####check_client_access pcre:/etc/postfix/dialups.pcre
permit

to
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination

is my config stupid or something? :)

I just found more errors.
Feb 19 12:28:49 alpha postfix/postfix-script: warning: /var/spool/postfix/etc/resolv.conf and /etc/resolv.conf differ
Feb 19 12:28:49 alpha postfix/postfix-script: warning: /var/spool/postfix/etc/nsswitch.conf and /etc/nsswitch.conf differ

it added 127.0.0.1 to resolv.conf but i don't use bind or something
the nsswitch.conf still looks the same. It just saved it over I think.<br><br>Post edited by: Martin, at: 2008/02/19 02:30

Thu, 02/21/2008 - 03:49 (Reply to #2)
webinger

I hade exactly the same Problem.
When I checked for some updates in PuTTY with apt-get update
apt-get dist-upgrade, it did some configuration file checks or something.
It checked bind, apache, postfix, mysql etc for their config files/or if they are available or sth like that. For example I don't use BIND DNS. It noticed it and activaed it again for me, but I didn't want to ;). Had to turn it of again and I had to reconfigure postfix to restore my postfix config file.
It looked a bit like an installer to me.

When I logged in to virtualmin after the 'update' it first wanted to recheck my config.
You think it is save to do the 1.0-14 update without saving my config files first? :)

Sun, 06/07/2009 - 07:19 (Reply to #3)
jezdez

Yeah, I had a look into the new postinst script first, which not uses this mechanism to check if it's an installation or an upgrade:

[code:1]my $install_p;

# Check for fresh install or explicit configure request, if it's not,
# we skip the configuration step
if ( $ARGV[0] eq "install" ) {
$install_p = 1;
}
else { $install_p = 0; }
[/code:1]

It worked for me.

Sun, 06/07/2009 - 07:19 (Reply to #4)
jezdez

Yeah, I had a look into the new postinst script first, which not uses this mechanism to check if it's an installation or an upgrade:

[code:1]my $install_p;

# Check for fresh install or explicit configure request, if it's not,
# we skip the configuration step
if ( $ARGV[0] eq "install" ) {
$install_p = 1;
}
else { $install_p = 0; }
[/code:1]

It worked for me.

Sun, 06/07/2009 - 07:19
jezdez

Ok, I had a look in /var/lib/dpkg/info/virtualmin-base.postinst and came across this piece of code which prevents the script to run when upgrading.

[code:1]$install_p = 1;
# Check for fresh install, if it's not, we skip the configuration step
if ( $ARGV[0] eq "upgrade" ) {
$install_p = 0;
}

[..]

# Stuff we only do on fresh install
if ( $install_p == "1" ) {
[..]
}[/code:1]

Which just doesn't work if I'm upgrading with "aptitude dist-upgrade" or "wajig daily-upgrade", I think.
It should just skip the setup process, shouldn't it?

Joe, what do you think?

Sun, 06/07/2009 - 07:19
jezdez

Ok, I had a look in /var/lib/dpkg/info/virtualmin-base.postinst and came across this piece of code which prevents the script to run when upgrading.

[code:1]$install_p = 1;
# Check for fresh install, if it's not, we skip the configuration step
if ( $ARGV[0] eq "upgrade" ) {
$install_p = 0;
}

[..]

# Stuff we only do on fresh install
if ( $install_p == "1" ) {
[..]
}[/code:1]

Which just doesn't work if I'm upgrading with "aptitude dist-upgrade" or "wajig daily-upgrade", I think.
It should just skip the setup process, shouldn't it?

Joe, what do you think?

Tue, 02/19/2008 - 01:20
webinger

Im sure he's sleeping right now ;)

Tue, 02/19/2008 - 05:47 (Reply to #8)
sgrayban

webmin/virtualmin should not be upgraded when upgrading the distro to a new version which is what you are doing with "dist-upgrade" because webmin/VM don't care -- they are platform independent for the most part.

Sun, 06/07/2009 - 07:19
jezdez

Ok, I had a look in /var/lib/dpkg/info/virtualmin-base.postinst and came across this piece of code which prevents the script to run when upgrading.

[code:1]$install_p = 1;
# Check for fresh install, if it's not, we skip the configuration step
if ( $ARGV[0] eq "upgrade" ) {
$install_p = 0;
}

[..]

# Stuff we only do on fresh install
if ( $install_p == "1" ) {
[..]
}[/code:1]

Which just doesn't work if I'm upgrading with "aptitude dist-upgrade" or "wajig daily-upgrade", I think.
It should just skip the setup process, shouldn't it?

Joe, what do you think?

Tue, 02/19/2008 - 14:45
Joe
Joe's picture

I have no idea. I'm kinda dumb about apt-get and dpkg. So, what are you saying we ought to be doing instead? Also check for "dist-upgrade" in ARGV[0]? I was under the impression that this would always be "upgrade" if this package is being upgraded and something else if it's a fresh installation of the package.

--

Check out the forum guidelines!

Wed, 02/20/2008 - 03:39 (Reply to #11)
jezdez

Seriously, I don't care. If servers go down because of an update which seems to be borked it's your responsibility to fix that. This is VERY frustrating.

On another thread you said "as the post installation script (the only thing contained in virtualmin-base) never runs when upgrading the package--only when doing a fresh install". Which is not true. The post-inst script ran on my server and on another server I know of. What's going on here??

Wed, 02/20/2008 - 09:59 (Reply to #12)
Joe
Joe's picture

<div class='quote'>On another thread you said &quot;as the post installation script (the only thing contained in virtualmin-base) never runs when upgrading the package--only when doing a fresh install&quot;. Which is not true. The post-inst script ran on my server and on another server I know of. What's going on here??</div>

I honestly don't know. I only know what the Debian packaging docs tell me (which isn't much).

What steps exactly did you follow to get this problem? I'd like to reproduce it.

Also, the postinstall shouldn't be dramatically damaging to the system--and we're happy to help get back to normal. I can even drop in on your box and straighten it out for you (you, too, Scott), if you'd like to email me the details.

I'm frankly baffled by these two problem reports. We just aren't seeing this behavior on our test systems.

--

Check out the forum guidelines!

Thu, 02/21/2008 - 01:15 (Reply to #13)
jezdez

<div class='quote'>What steps exactly did you follow to get this problem?</div>

I just used &quot;wajig daily-upgrade&quot;, which performs an &quot;apt-get update&quot; then an &quot;apt-get dist-upgrade&quot;.

Wed, 02/20/2008 - 11:07 (Reply to #14)
Joe
Joe's picture

<div class='quote'>If servers go down because of an update which seems to be borked it's your responsibility to fix that.</div>

I'm just going back over all of these threads to try and figure out what exactly what you're seeing...and this struck me...

What service went down during the update, or are we just talking about Virtualmin/Webmin behaving badly? (e.g. are you saying mail or web or something actually stopped working?)

--

Check out the forum guidelines!

Thu, 02/21/2008 - 01:28 (Reply to #15)
jezdez

With virtualmin-base_1.0-13_all there were several issues:

1. Postfix couldn't deliver received emails and threw the following error repeatedly until I reset the according settings in main.cf:
[code:1]Feb 20 09:07:48 tichy postfix/local[12042]: fatal: main.cf configuration error: mailbox_size_limit is smaller than message_size_limit[/code:1]

I now have the following settings:
[code:1]
mailbox_size_limit = 21474836480
message_size_limit = 51200000
[/code:1]

2. The firewall scripts in the postinst completely blocked any traffic (!) when they were executed. That means: I was instantly cut off the server, not knowing what the hell was going on. I had to hard-reset the server machine with the emergency system of my hoster. I do run shorewall software firewall though, maby this conflicts with the firewall setting made in the postinst.

3. On one of two server I know of the local Bind stopped working. It just doesn't takes any lookup requests. I had to disable the feature in Virtualmin and remove the entry from resolv.conf to resolve that.

BUT.

virtualmin-base_1.0-14_all worked as hoped, the postinst script correctly skipped the configure script now. The bind issue is still not resolved.

Thanks for your fast help, though this was a rough ride.

Thu, 02/21/2008 - 04:00
jezdez

Ooops, there is a typo. The sentence should have been: &quot;Yeah, I had a look into the new postinst script first, which NOW uses this mechanism to check if it's an installation or an upgrade:&quot; Sorry.