7.20 - Forced to reload the entire box..

essh good to know, i am gonna update my three boxes tomorrow.  i have static gateway routes set though, not static interface routes.

essh good to know, i am gonna update my three boxes tomorrow.  i have static gateway routes set though, not static interface routes.

sirebral,

let me ask some questions:
- did you reload the box with 7.200 or 7.10x? (=is it now working with 7.200 and your configuration?)
- do you have some logfiles from the failing box?
- did you install some preview RPMs from support on that second box?

cheers
~marcel

Hi.
I have the similar situation.
After upgrading to 7.2 , the Middleware stop after 2-3 hours, and I have no connections to the Internet and to my DMZ.
If I restore the configuration, restart Astaro or restart MDW service, everything get back to normal for the next 2-3 hours. 

[:(]

Goldy,

there are some important things to know about Middleware:
- it is the main services for writing configuration and stopping/starting services
- it runs only on demand (e.g. WebAdmin changes, IP changes, DNS host changes, RAS access, ..)
- it stops/restarts all services once it is started to have them in a defined state
- it 'normally' does not leave the system in a broken state if it stops working after a complete run
- it is restarted by selfmonitor if it dies

In order to help here, you'd need to add some details about your problem:
- check if mdw is running when your problem occurs (ps axf | grep mdw)
- check selfmon.log if it tries starting mdw at the time your problem occurs
- check /var/log/mdw.log and /tmp/mdwdebug.log for errors
- check which other logs changed when your problems occurs (ls -ltr /var/log/) and check them for possible problems

hope this helps
~marcel

I updated my boxes this morning and only had one small issue, for some reason the box altered one of my packet rules after updating.  It was an easy fix but still curious.

tiredofnick: what exactly has been changed or what was not working after applying the Up2Date?

well it had turned a rule "off" but the green light said it was "on."  The rule definetly had been on and working correctly right before i updated.  to fix it, i just turned the rule off and on again and it started working fine. :shrug:

that particular box has always been a little funny.  i recently purchased an update to my support license, when i applied the new license to that box it "forgot" a bunch of its routes (static and gateway) and i had to rebuild the route table to get it working correctly.  I even tried rolling back to a backup config and it didn't work!

but like i said, all is well now.

Hi Marcel.

I'm sending you today's MDW log.
About the other suggestion - right now I can't stop my system, so i have to restart mdw fast as possible in order to keep my system running.

I'll try tomorrow morning.

Thanks…
[:)]

tiredofnick: do you use any kind of DNS definitions in your rules or routes which might not be updated/resolved and therefor not set?

Goldy: thanks for the log, can you please upload /tmp/mdwdebug.log from that box after this problem has occured but _before_ you reboot the box? Do you use QoS?

marcel:  nope, nothing like that.  and now that the day has progressed and people are at my sites i found an interesting problem, maybe you can advise a better stratagey? 

here is some background, I have three sites, which are all interconnected by a private WAN (PWAN).  2 of those sites have servers in a dmz.

And here is what happened.  Something changed in the order in which packets are processed (or something...).  Before we routed on just the PWAN address, since everything that is in the DMZ gets NAT'ed to its pwan address this worked fine.  Now NAT-ing happens before routing.

this is what was happening:
packet comes in bound for the pwan address 192.168.100.30 -> NAT translates the address to the DMZ address of 192.168.10.30 -> routes take over, but no route is explicitly set for 10.30 only for 100.30 , packet drops.

Obviously to fix it I just added in the apporpriate routes for all the DMZ ip addresses instead of the PWAN addresses, so i guess i had it setup incorrectly all along.  but its funny that it worked for so long and then died with this update.

make sense?

Hi Marcel

right now it's happening more often (I think there is more load on the Astaro).

Yes I'm using QOS.
Concerning QOS - I have noticed there is no way to config the priority of the new Traffic Selectors (DSCP).

Unfortunately, I can't leave my 500 users in this situation, So I guess tomorrow I'm going back to 7.104...