This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Astaro 7.507 firewall could not get latest pattern?

"cc get ips pattern_version" from ssh console says: ips->pattern_version = "u2d-ips-7-177:u2d-ips-7-178:1276501182"
Webadmin says: "Your patterns are up to date"

Live Log (Up2Date messages) says:

2010:10:13-13:26:02 router audld[5647]: Starting Up2Date Package Downloader (Version 1.57)
2010:10:13-13:26:02 router audld[5647]: patch up2date possible
2010:10:13-13:26:14 router audld[5647]: id="3701" severity="info" sys="system" sub="up2date" name="Authentication successful"
2010:10:13-13:26:30 router audld[5647]: id="3707" severity="info" sys="system" sub="up2date" name="Successfully synchronized fileset" status="success" action="download" package="ips"
2010:10:13-13:26:30 router audld[5647]: id="3707" severity="info" sys="system" sub="up2date" name="Successfully synchronized fileset" status="success" action="download" package="avira"
2010:10:13-13:26:30 router auisys[5750]: Starting Up2Date Package Installer (Version 1.65)
2010:10:13-13:26:30 router auisys[5750]: Searching for available up2date packages for type 'geoip'
2010:10:13-13:26:30 router auisys[5750]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="preinst_check" package="geoip"
2010:10:13-13:26:35 router auisys[5750]: Searching for available up2date packages for type 'ohelp7'
2010:10:13-13:26:35 router auisys[5750]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="preinst_check" package="ohelp7"
2010:10:13-13:26:41 router auisys[5750]: Searching for available up2date packages for type 'clam'
2010:10:13-13:26:41 router auisys[5750]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="preinst_check" package="clam"
2010:10:13-13:26:46 router auisys[5750]: Searching for available up2date packages for type 'ips'
2010:10:13-13:26:46 router auisys[5750]: Installing up2date package file '/var/up2date//ips/u2d-ips-7.173-193.patch.tgz.gpg'
2010:10:13-13:26:46 router auisys[5750]: Verifying up2date package signature
2010:10:13-13:26:46 router auisys[5750]: Unpacking installation instructions
2010:10:13-13:26:46 router auisys[5750]: Unpacking up2date package container
2010:10:13-13:26:46 router auisys[5750]: Running pre-installation checks
2010:10:13-13:26:46 router auisys[5750]: Starting up2date package installation
2010:10:13-13:26:51 router auisys[5750]: >=========================================================================
2010:10:13-13:26:51 router auisys[5750]: Failed installing RPM (command: 'rpm -U /var/up2date//ips-install/u2d-ips-7.193/rpms/u2d-ips-7.173-193.patch.rpm')
2010:10:13-13:26:51 router auisys[5750]:
2010:10:13-13:26:51 router auisys[5750]: 1. Internal::Systemstep::real_installation:2417() auisys.pl
2010:10:13-13:26:51 router auisys[5750]: 2. main:[:P]erform_work:1034() auisys.pl
2010:10:13-13:26:51 router auisys[5750]: 3. main::auisys_prepare_and_work:558() auisys.pl
2010:10:13-13:26:51 router auisys[5750]: 4. main::top-level:35() auisys.pl
2010:10:13-13:26:51 router auisys[5750]: |=========================================================================
2010:10:13-13:26:51 router auisys[5750]: Error details:
2010:10:13-13:26:51 router auisys[5750]: (stdout):$VAR1 = [];
2010:10:13-13:26:51 router auisys[5750]: (stderr):$VAR1 = [
2010:10:13-13:26:51 router auisys[5750]: 'error: unpacking of archive failed on file /var/pattern/ips/2.8.3.2/base/snortgroups.ph;4cb5977b: cpio: open failed - No such file or directory
2010:10:13-13:26:51 router auisys[5750]: '
2010:10:13-13:26:51 router auisys[5750]: ];
2010:10:13-13:26:51 router auisys[5750]:
2010:10:13-13:26:51 router auisys[5750]: 1. Internal::Systemstep::real_installation:2418() auisys.pl
2010:10:13-13:26:51 router auisys[5750]: 2. main:[:P]erform_work:1034() auisys.pl
2010:10:13-13:26:51 router auisys[5750]: 3. main::auisys_prepare_and_work:558() auisys.pl
2010:10:13-13:26:51 router auisys[5750]: 4. main::top-level:35() auisys.pl
2010:10:13-13:26:56 router auisys[5750]: |=========================================================================
2010:10:13-13:26:56 router auisys[5750]: Errors during the installation detected, NOT setting new version
2010:10:13-13:26:56 router auisys[5750]:
2010:10:13-13:26:56 router auisys[5750]: 1. Internal::Systemstep::real_installation:2444() auisys.pl
2010:10:13-13:26:56 router auisys[5750]: 2. main:[:P]erform_work:1034() auisys.pl
2010:10:13-13:26:56 router auisys[5750]: 3. main::auisys_prepare_and_work:558() auisys.pl
2010:10:13-13:26:56 router auisys[5750]: 4. main::top-level:35() auisys.pl
2010:10:13-13:26:56 router auisys[5750]: |=========================================================================
2010:10:13-13:26:56 router auisys[5750]: id="371O" severity="error" sys="system" sub="up2date" name="Fatal: Up2Date package installation failed: Errors during the package installation, installation failed (10)" status="failed" action="install" code="10" package="ips"
2010:10:13-13:26:56 router auisys[5750]:
2010:10:13-13:26:56 router auisys[5750]: 1. main::alf:73() auisys.pl
2010:10:13-13:26:56 router auisys[5750]: 2. main:[:P]erform_work:1080() auisys.pl
2010:10:13-13:26:56 router auisys[5750]: 3. main::auisys_prepare_and_work:558() auisys.pl
2010:10:13-13:26:56 router auisys[5750]: 4. main::top-level:35() auisys.pl


This thread was automatically locked due to age.
  • The issue is not widespread from what I've seen, but we are  are aware of this and we're working on it.  Traffic will not be blocked, IPS doesn't fail- the system will just keep trying to apply the pattern.

    Jack, how can you say this was not widespread. The original poster had problems on v7, I tried it on v8.001 and professor had the problem with 8.002. It probably wasn't reported widely because it didn't break anything.

    I am getting deeply concerned by the issues with up2dates lately. Astaro has always been rock solid and quick to fix each and every issue that I have had. But for some reason the QA guys that are doing the testing for up2dates are not getting the message. You cannot keep on pushing bad up2dates and say it was not widespread or only a few people were effected or nobody noticed. This should not happen period. As a leader in the UTM world astaro really needs to address this even if it stops/delays any future development in my opinion. You cannot have tarnished reputation in software/security business no matter how good of a product you are pushing. Just my 2 cents.

    Regards
    Bill.
  • it works fine now on Astaro 7.507.
    thanks to Astaro team for quickly fixing it.
  • Bill raises good questions, here are >>MY
  • Most importantly to me: there was no real impact from this, other than a delay of a few hours in updating one IPS pattern set

    We can agree to disagree that this was by design and not some kind of divine intervention as the systems could easily have gone down as they previously have.

    The fact that an IPS pattern failed to install properly in some systems, but did not impede traffic flow and was corrected without intervention tells me that Astaro's efforts at building more resiliency into the up2date system are working.

    This is what my post was all about. You don't get many second chances as a software vendor (ok you do if you are microsoft). It seems to me that the broken updates are being pushed at a greater frequency than I ever recall. Granted astaro is not the same simple astaro NAT device that I loved back in v4 days and complicated astaro of today takes meticulous handling but something is definitely not right. 

    I can buy the argument that the software appliance/ virtual appliances may act differently to different up2date packages but when an astaro supplied hardware device goes down or fails to update due to a buggy pattern push, that is nothing but lack of quality control and is definitely not the time to congratulate everybody on their efforts yet. 

    If you disagree, or want to vent- I'm easy to find

    Jack, after Bob (BAlfson), I think I am the biggest astaro cheerleader so thanks but I don't need to vent and my post by no means was directed toward embarrassing anybody. I have used astaro since I first found out about it in v4 days and have used it with every version ever since then. I even get involved in the beta testing lately just to get my voice heard on the few minor things that I would like to improve. I love everything about the product and have nothing but kind words for the development team, the management, and even the moderators. My concern was about the continued trend of bad updates which should have been completely fixed by now but for some reason hasn't. 

    Best Regards
    Bill.
  • Interesting.  I glanced at Jack's response and thought that was the end of the thread, but then Bill (Billybob) came back with a though-provoking response.

    To add perspective...  We once were in the business of rolling out small networks to widely-dispersed branch offices.  Of course, we had a strong team of MCSEs that would create flawless "gold disks" so that each device of a type was installed identically every time.  In addition to that, I wanted it to be clear to everyone when a team left that everything was working correctly.  Among the "tools" we used was a simple program that ran on each PC and printed a confirmation page.  Counting those pages was a part of the customer's office manager's acceptance procedure.  We always designed a process and "tests" that could be confirmed by the client's non-technical staff.

    All Up2Dates and pattern updates should work correctly every time.  If one doesn't install correctly, the Astaro should "phone home" in addition to writing the log file.  There always will be  a few Astaros that will have a problem, but this approach would, at least, serve as a way to alert Astaro to withdraw a truly problematic update quickly.

    Since pattern updates typically install in seconds, the install program could send a "starting" message to Astaro; if the "ending" message didn't arrive within a minute, an alert could be generated.  This could be expanded with some method of confirming the absence of anything like the May 7th blockage.

    Anyway, the idea is to be proactive, and not wait for a customer to complain.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA