Sophos UTM showing duplicate Endpoint Protection Computer entries since update to 9.503-4 (came from 9.502-4)

Hi and welcome to the UTM Community!

Do you have IPv6 activated on those endpoint PCs?  What happens if you disable IPv6 on one of them and delete/re-install Endpoint on that PC?

How many entries do you see for the following?

cc get epp endpoints

Cheers - Bob

Hello Bob,

I have IPv6 disabled already before the update accross all computers.

The command you gave me shows the following result:

firewall:/root # cc get epp endpoints
[
          'REF_EppEndWin7614914',
          'REF_EppEndWinxp32tes',
          'REF_EppEndArbeitstie',
          'REF_EppEndKreativitt',
          'REF_EppEndNet01w10',
          'REF_EppEndPol7f',
          'REF_EppEndNetsrv2',
          'REF_EppEndNepali',
          'REF_EppEndBldnussen',
          'REF_EppEndNet03'
        ]

So I guess this is a bug in the WebGUI showing duplicate endpoints and client installations are fine. The list from cc command is correct according to my license documentation I keep track of.

Interesting.  What do you see in WebAdmin if you do the following? (This will delete all history in your graphs and databases.  It will not affect your logs.)

/etc/init.d/postgresql92 rebuild

Cheers - Bob

Log:

/etc/init.d/postgresql92 rebuild
Rebuilding PostgreSQL database, all reporting data will be lost!
Enter "yes" to continue...
yes
:: Stopping PostgreSQLcould not change directory to "/root"
                                                                                                                                                                  done
:: Initializing the PostgreSQL databasecould not change directory to "/root"
                                                                                                                                                                  done
:: Starting PostgreSQLpg_ctl: could not start server
Examine the log output.
                                                                                                                                                                  failed
:: Restarting SMTP Proxy
:: Stopping SMTP Proxy
[ ok ]
:: Starting SMTP Proxy
[ ok ]
[ ok ]

---

After this action, the endpoint summary page is blank.

I forgot to mention that I did the recommended update to PGSQL ARCH 64 on 2017-10-11.

The config /var/storage/pgsql92/postgres.default file shows:

# written by 9.5 Up2Date

POSTGRES_ARCH="64"

--

Can you please help me start pgsql again? Will sophos cease to function without it?

I forgot to mention that I did the recommended update to PGSQL ARCH 64 on 2017-10-11.

The config /var/storage/pgsql92/postgres.default file shows:

# written by 9.5 Up2Date

POSTGRES_ARCH="64"

--

Can you please help me start pgsql again? Will sophos cease to function without it?

Did you run that rebuild command as root?

Cheers - Bob

Yes, Before launching the command I did a SSH login as "loginuser" and then used "su -" to get the root prompt. SSH command line showed "firewall:root#".

You can try:

/etc/init.d/postgresql92 restart

Any luck with that?

Cheers - Bob

 This is my result - the command failed in a sub-step:

Ok, now I did

tailf /var/log/system.log

/etc/init.d/postgresql92 start

and got the following Log:

2017:11:02-08:55:28 firewall postgres[24563]: [1-1] LOG:  loaded library "pg_stat_statements"
2017:11:02-08:55:28 firewall postgres[24563]: [2-1] FATAL:  could not create shared memory segment: Cannot allocate memory
2017:11:02-08:55:28 firewall postgres[24563]: [2-2] DETAIL:  Failed system call was shmget(key=5432001, size=1137106944, 03600).
2017:11:02-08:55:28 firewall postgres[24563]: [2-3] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space, or exceeded your kernel's SHMALL parameter.  You can either reduce the request size or reconfigure the kernel with larger SHMALL.  To reduce the request size (currently 1137106944 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
2017:11:02-08:55:28 firewall postgres[24563]: [2-4]     The PostgreSQL documentation contains more information about shared memory configuration.

But I did not change the memory size on the machine - it was running fine before the attempt to rebuild.

Maybe this issue is related: https://community.sophos.com/products/unified-threat-management/f/management-networking-logging-and-reporting/96996/help---reporting-no-longer-working/352468

9.503-4 with 5 GB of total memory assigned to the VM.

Ok, some news:

I issued "killall httpproxy", waited for about one minute for the process to terminate properly. Then, with more than 54% of RAM freed up I could issue

/etc/init.d/postgresql92 start

with success. (done)