Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 2 subscribers
  • Views 1889 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

Yet another "reporting broken"

Brainscanner
Hi everybody,

somewhen during normal runtime with 7.303 (now installed 7.304) the system suddenly stopped some reporting features (see screenshot).

Same goes for the executive report. Creating it manually doesn't really work anymore. I just get the "is beeing generated".
Very strange: I've had the weekly and monthly reports sent to me. These don't work anymore, but the daily does [8-)]

But... it lacks of a lot of values (see executive-screenshots). Framed are the values which are definitely wrong.

Can somebody help me out? Reporting is the only thing, the firewall isself is working fine. But it's a very nice feature :-)


This thread was automatically locked due to age.
  • 0
    Hi,
    can you please take a look into the system.log? There should be some information we can use to pinpoint the problem; if you can see postgreSQL errors in there it's probably related to the problems we've seen.

    Cheers,
     andreas
  • 0 in reply to andreas
    You mean that one, don't you? "System messages"

    It's pretty big (1,7 MB since midnight), but no string like "postgreSQL" in it. It doesn't seem to contain sensitive information (does it?), so I've attached it to this post.
    system.zip
  • 0 in reply to Brainscanner
    From your logfile:

    2008:10:24-00:02:02 (none) postgres[4531]: [3-1] ERROR:  could not open relation 17068/16519/16534: No such file or directory

    (and lots of more errors like this)

    According to that log, at least most (if not all) of the reporting tables are broken. If you don't mind losing what might still be existing, you can just re-initialize the reporting tables:
    /etc/init.d/ulog stop
    /etc/init.d/syslogng stop
    /var/storage/pgsql/init/reporting_db_init.sh
    /etc/init.d/syslogng start
    /etc/init.d/ulog start

    If not, there's a lot of manual work involved checking which tables are broken, drop views, indexes, tables, re-create them, ... ... and you might better check with the support team for this.

    Cheers,
     andreas

    PS: It just came to my attention that you need a root shell with a complete environment for the reporting_db_init.sh script to work. So you need to become root using "su -" (the minus is important, it means you want to have a login shell) before using the above script.
  • 0 in reply to andreas
    Done so (reinitialize). Pitty for the data, but it's not worth much if it's not up-2-date :-)

    Thank you very very much for your kind help!
  • 0 in reply to Brainscanner
    This seems to have hurt my F/W too.  I'll try reinitializing things too...Glad I'm using this for home use and not a corporate solution where I'd be reliant on the logs to retain...Yikes!  Did someone drop the ball with this update?  Just curious...Doesn't really matter though I suppose...
  • 0 in reply to atarso
    Atarso, if you had a large corporate installation and concern about keeping log files, you would have the logs created on a remote server.  If you want to copy the logs off your Astaro, you can use WinSCP and a little linux knowledge.  Doing the copying requires things that would cause you to lose support, but the subsequent reload from scratch solves that problem.

    Cheers - Bob
  • 0 in reply to BAlfson
    Hi there all, 

    Astaro has an integrated log archival functionality, where you can configure the ASG to rotate the logfiles each night to a remote server using SSH, SMB/CIFS, SMTP or FTP.

    This way you can save your compressed and rotated logfiles on a central server. 
    For realtime log synchronization you can use Remote Syslog to stream the logs to another server. 

    regards
    Gert
  • 0 in reply to Gert Hansen
    Hi,
    just to clear that up since it seems to get confused a lot - this is not about the logs. The logfiles and the logfile archives are not in any way touched by this operation. 

    When a log event is generated, the reporting subsystem checks if this is an event that needs to be processed by the reporting, and if yes, it is written to the reporting databases and/or other reporting backend storage systems. This is a one-time event, so if you delete the reporting database afterwards, you lose the reporting event, but not the log data which generated the event. It is still possible to see every event in the log (e.g. for forensics).

    Cheers,
     andreas
  • 0 in reply to andreas
    From your logfile:

    (and lots of more errors like this)

    According to that log, at least most (if not all) of the reporting tables are broken. If you don't mind losing what might still be existing, you can just re-initialize the reporting tables:
    /etc/init.d/ulog stop
    /etc/init.d/syslogng stop
    /var/storage/pgsql/init/reporting_db_init.sh
    /etc/init.d/syslogng start
    /etc/init.d/ulog start

    If not, there's a lot of manual work involved checking which tables are broken, drop views, indexes, tables, re-create them, ... ... and you might better check with the support team for this.

    Cheers,
     andreas


    I came upon this same error and ran the above commands as "su". But I got a lot of "relation "blahblahblah" already exists". Then the last line says "psql: FATAL:  role "root" does not exist".
    Is this expected behavior?
  • 0 in reply to JimmyM
    Solved in the other thread: https://community.sophos.com/products/unified-threat-management/astaroorg/f/53/t/32246
    Seems like I forgot to stick the note regarding the "su - " in here, sorry guys.

    Cheers,
     andreas