Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 4 subscribers
  • Views 1438 views
  • Users 0 members are here
Options
Suggested
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

up2date error: Error in GPG verification (return code: 256)

JonEtkins

I'm seeing the following error from my slave/standby node.  The primary node appears to be working fine.

2021:05:10-12:02:04 astaro-2 auisys[11395]: Install u2d packages <aptp>
2021:05:10-12:02:04 astaro-2 auisys[11395]: Starting installing up2date packages for type 'aptp'
2021:05:10-12:02:04 astaro-2 auisys[11395]: Installing up2date package: /var/up2date/aptp/u2d-aptp-9.38727-38728.patch.tgz.gpg
2021:05:10-12:02:04 astaro-2 auisys[11395]: Verifying up2date package signature
2021:05:10-12:02:04 astaro-2 auisys[11395]: >=========================================================================
2021:05:10-12:02:04 astaro-2 auisys[11395]: id="371F" severity="error" sys="system" sub="up2date" name="Fatal: Could not extract tar from gpg: 'Error in GPG verification (return code: 256)'" status="failed" file="/var/up2date/aptp/u2d-aptp-9.38727-38728.patch.tgz.gpg" action="install" package="aptp"
2021:05:10-12:02:04 astaro-2 auisys[11395]:
2021:05:10-12:02:04 astaro-2 auisys[11395]: 1. Modules::Logging::alf:100() /</sbin/auisys.plx>Modules/Logging.pm
2021:05:10-12:02:04 astaro-2 auisys[11395]: 2. Modules::Auisys::Installer::Systemstep::_unpack_pkg:306() /</sbin/auisys.plx>Modules/Auisys/Installer/Systemstep.pm
2021:05:10-12:02:04 astaro-2 auisys[11395]: 3. Modules::Auisys::Installer::Systemstep::install:91() /</sbin/auisys.plx>Modules/Auisys/Installer/Systemstep.pm
2021:05:10-12:02:04 astaro-2 auisys[11395]: 4. Modules::Auisys::Up2DatePackages::install:143() /</sbin/auisys.plx>Modules/Auisys/Up2DatePackages.pm
2021:05:10-12:02:04 astaro-2 auisys[11395]: 5. Modules::Auisys::QueueIterator::process_qfiles:81() /</sbin/auisys.plx>Modules/Auisys/QueueIterator.pm
2021:05:10-12:02:04 astaro-2 auisys[11395]: 6. main::main:298() auisys.pl
2021:05:10-12:02:04 astaro-2 auisys[11395]: 7. main::top-level:35() auisys.pl
2021:05:10-12:02:04 astaro-2 auisys[11395]: <=========================================================================
Any idea where I should start?  I'm unable to ssh to the standby node (see earlier post).


This thread was automatically locked due to age.
  • 0

    Interestingly, the problem appears to follow the inactive node - if I trigger a takeover so that Node 2 becomes the primary, then I get this error on Node 1!

  • 0 in reply to JonEtkins

    Interesting, Jon - please let us know what Sophos Support has to say about this strange behavior.  I bet you're right that the same thing is also causing the SSH issue.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi, Bob.  Unfortunately I'm a mere Home License user, so no access to Sophos Support outside this forum.  I'm not sure that the SSH issue is actually related, but it is preventing me from accessing the slave node to try manually deleting the file that it appears to be choking on.

  • 0 in reply to JonEtkins

    OK, I just looked at your recent SSH thread.  I think I'd try the following:

    1. Get several config backups off the active node.
    2. Deactivate High Availability.  This will cause the Slave to do a factory reset and shut down
    3. After the Slave is shut down, Re-enable HA.
    4. Power up the Slave with your fingers crossed.

    Any luck with that?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Thanks, Bob.  I was eventually able to gain access to the slave node (see other thread) and delete the offending .gpg file, after which it all appears to be back to normal.  But if I encounter any other weirdness, I probably will go down the reset-and-reconnect route.

    Speaking of which, do you happen to know which eth port the software version checks for an HA link by default?  I have mine configured using eth3, but when I boot one after a factory reset, it doesn't detect the other active node and I have to go through basic setup before I can configure it to use eth3 as the HA link and get the pair working.  Since they're both virtualized, It would be trivial to switch that link to whichever one it wants to use by default.  Should it be eth2?

  • 0 in reply to JonEtkins

    Default is definitely eth3 on Sophos appliances.  Elsewhere, you'd have to dig into the logs of the virtualization server to see.

    This might also be a problem with the configuration in the Master.  Here's the checklist I give to my clients when they replace a node in HA:

    1. If needed, do a quick, temporary install so that the new device can download Up2Dates.
    2. Apply the Up2Dates to the same version as the current unit, do a factory reset and shutdown.
    3. On the current UTM in use, on the 'Configuration' tab of 'High Availability':
        a. Enable Hot-Standby  
        b. Select eth3 as the Sync NIC
        c. Configure it as Node_1
        d. Enter an encryption key (I've never found a need to remember it)
        e. Select 'Enable automatic configuration of new devices'
        f. I prefer to use 'Preferred Master: None' and 'Backup interface: Internal'
    4. Cable eth3 to eth3 on the new device.
    5. Cable all of the other NICs exactly as they are on the original UTM.
    6. Power up the new device and wait for the good news. Wink

    Cheers - Bob

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