Can't login to webmin [7.305] - Page 2

LewisR · #11 (**permalink**) 01-01-2009, 03:55 AM

Hmmm... Barry, I'm wondering what you might have turned on which is causing such a run up on the net accounting file. This is from one of my servers, now up 42 days:

Code:

secmgr-va:/tmp # uptime
 10:50pm  up 42 days  9:04,  1 user,  load average: 0.04, 0.13, 0.16
secmgr-va:/tmp # ll /tmp/
total 83124
drwxrwxrwx 3 root     root         4096 Dec 26 01:19 FileCache
-rw------- 1 root     root        12288 Dec 31 22:31 aua_auth_cache.db
-rw-r--r-- 1 root     root            0 Dec 31 22:31 aua_auth_cache.db.lock
-rw------- 1 root     root        24576 Dec 26 19:13 aua_confd_cache.db
-rw-r--r-- 1 root     root            0 Dec 31 22:31 aua_confd_cache.db.lock
-rw-r--r-- 1 root     root          196 Nov 19 10:08 auadebug.log
-rw------- 1 root     root     53427703 Dec 31 22:50 confd-debug.log
-rwxr-xr-x 1 root     root       219300 Nov 19 10:23 ctasd
-rw-rw-rw- 1 root     root        21943 Dec 31 22:27 ctasd.cache
-rw-r--r-- 1 root     root           34 Dec 31 22:39 ctasd_connect_check.out
-rw-rw-rw- 1 root     root       174796 Dec 14 04:25 cteng_10_2_11229246669.dat
-rw-rw-rw- 1 root     root         3116 Dec 28 03:30 cteng_10_2_21230452731.dat
-rw-rw-rw- 1 root     root        68192 Dec 31 13:05 cteng_1_1_101230746614.dat
-rw-rw-rw- 1 root     root        63960 Dec 25 01:04 cteng_1_1_111230184962.dat
-rw-rw-rw- 1 root     root        67020 Dec 30 07:57 cteng_1_1_121230641559.dat
-rw-rw-rw- 1 root     root        59396 Dec 30 09:02 cteng_1_1_131230645499.dat
-rw-rw-rw- 1 root     root        45520 Dec 31 19:42 cteng_1_1_141230770333.dat
-rw-rw-rw- 1 root     root        52500 Dec 31 09:40 cteng_1_1_161230734379.dat
-rw-rw-rw- 1 root     root       104652 Dec  7 07:02 cteng_1_1_181228651334.dat
-rw-rw-rw- 1 root     root        78780 Dec 30 07:06 cteng_1_1_201230638591.dat
-rw-rw-rw- 1 root     root        56724 Dec 26 02:04 cteng_1_1_211230274976.dat
-rw-rw-rw- 1 root     root        41552 Dec 30 06:16 cteng_1_1_221230635696.dat
-rw-rw-rw- 1 root     root        52588 Dec 30 08:22 cteng_1_1_231230643303.dat
-rw-rw-rw- 1 root     root        50636 Dec 31 16:36 cteng_1_1_41230759092.dat
-rw-rw-rw- 1 root     root        54016 Dec 31 06:54 cteng_1_1_71230724351.dat
-rw-rw-rw- 1 root     root        60136 Dec 31 09:50 cteng_1_1_81230734810.dat
-rw-rw-rw- 1 root     root        70648 Dec 27 04:03 cteng_1_1_91230368573.dat
-rw-rw-rw- 1 root     root       293552 Dec 31 19:42 cteng_1_2_131230770321.dat
-rw-rw-rw- 1 root     root       243208 Dec 30 08:37 cteng_1_2_141230644021.dat
-rw-rw-rw- 1 root     root       202992 Dec 29 09:03 cteng_1_2_151230559393.dat
-rw-rw-rw- 1 root     root       227832 Dec 30 14:43 cteng_1_2_161230665976.dat
-rw-rw-rw- 1 root     root       252012 Dec 30 06:56 cteng_1_2_171230638088.dat
-rw-rw-rw- 1 root     root       312072 Dec 31 09:05 cteng_1_2_181230732211.dat
-rw-rw-rw- 1 root     root       295636 Dec 31 04:31 cteng_1_2_201230715699.dat
-rw-rw-rw- 1 root     root       265480 Dec 30 03:20 cteng_1_2_211230625199.dat
-rw-rw-rw- 1 root     root       252092 Dec 31 08:29 cteng_1_2_221230730130.dat
-rw-rw-rw- 1 root     root       273944 Dec 31 00:20 cteng_1_2_231230700619.dat
-rw-rw-rw- 1 root     root       232896 Nov 30 18:03 cteng_1_2_241228086145.dat
-rw-rw-rw- 1 root     root       133292 Dec 29 02:23 cteng_1_2_251230535384.dat
-rw-rw-rw- 1 root     root       195132 Dec 31 10:25 cteng_1_2_261230737090.dat
-rw-rw-rw- 1 root     root       304936 Dec 31 07:34 cteng_1_2_271230726850.dat
-rw-rw-rw- 1 root     root       272512 Dec 31 07:49 cteng_1_2_281230727549.dat
-rw-rw-rw- 1 root     root       262964 Dec 31 18:37 cteng_1_2_291230766473.dat
-rw-rw-rw- 1 root     root       264608 Dec 31 11:05 cteng_1_2_301230739411.dat
-rw-rw-rw- 1 root     root       150640 Dec 31 15:21 cteng_1_2_311230754736.dat
-rw-rw-rw- 1 root     root       223340 Dec 31 07:39 cteng_1_2_41230726863.dat
-rw-rw-rw- 1 root     root       294980 Dec 31 06:54 cteng_1_2_71230724349.dat
-rw-rw-rw- 1 root     root        14108 Dec 16 05:27 cteng_3_2_11229423149.dat
-rw-rw-rw- 1 root     root        16804 Nov 19 10:13 cteng_8_2_11223394495.dat
-rw-rw-rw- 1 root     root         8680 Nov 19 10:13 cteng_8_2_21224089394.dat
-rw-rw-rw- 1 root     root          831 Dec 31 19:42 cteng_index.dat
-rw-rw-rw- 1 root     root            0 Dec 31 22:50 cteng_index.lck
-rw-rw-rw- 1 root     root            0 Dec 31 22:50 cteng_sync.lck
-rw------- 1 root     root        20480 Dec 31 22:50 dnsresolver.db
-rw-r--r-- 1 root     root            0 Dec 31 22:50 dnsresolver.db.lock
-rw-r--r-- 1 root     root            0 Nov 19 10:08 dnsresolver.log
-rw-r--r-- 1 root     root           69 Nov 23 13:36 ha_log.txt
-rw-r--r-- 1 root     root          188 Dec 31 22:50 ipsec_status.debug
-rw-r--r-- 1 root     root           27 Nov 23 13:36 lcd
-rw------- 1 root     root       151759 Dec 31 02:30 mdwdebug.log
-rw------- 1 root     root     13565952 Dec 31 22:47 netacc_sql.cache
-rw-r--r-- 1 root     root            0 Dec 31 22:47 netacc_sql.cache.lock
drwxr-xr-x 2 root     root         4096 Nov 23 13:42 pdk-root
-rw------- 1 postgres postgres       77 Nov 19 10:08 postgres.log
-rw------- 1 root     root      9494528 Dec 31 22:47 sql.cache
-rw-r--r-- 1 root     root            0 Dec 31 22:47 sql.cache.lock
-rw-r--r-- 1 root     root         4095 Dec 10 22:39 traceable_system.12531.log
-rw-r--r-- 1 root     root          847 Dec 10 22:43 traceable_system.13110.log
-rw-r--r-- 1 root     root         2946 Nov 19 18:29 traceable_system.15290.log
-rw-r--r-- 1 root     root           68 Nov 19 18:31 traceable_system.15515.log
-rw-r--r-- 1 root     root        41905 Nov 19 19:51 traceable_system.15724.log
-rw-r--r-- 1 root     root          927 Nov 23 13:47 traceable_system.16132.log
-rw-r--r-- 1 root     root         1722 Nov 23 14:06 traceable_system.16587.log
-rw-r--r-- 1 root     root           75 Dec 26 21:06 traceable_system.21909.log
-rw------- 1 root     root      2150400 Dec 31 22:47 websec_sql.cache
-rw-r--r-- 1 root     root            0 Dec 31 22:47 websec_sql.cache.lock

The above is running 7.305, too, BTW, on a mirrored pair of 16GB Ultra320 SCSI's.

BarryG · #12 (**permalink**) 01-02-2009, 03:11 AM

Bruce, it was a fresh config in 7.0xx, upgraded gradually to 7.305.

The file is still growing; it's at 197MB right now, and /tmp is 34% full.

I also see that PostGreSQL is using all available CPU, but I just tried to go into Reporting-NetworkUsage-Accounting, so I'm not sure if it's still working on that. (The report hasn't loaded after several minutes.)

I'm also seeing high RAM and SWAP usage... 211MB swapped right now.

TOP output, sorted by 'M'emory:

Code:

Mem:    516220k total,   503472k used,    12748k free,     3300k buffers
Swap:  1052248k total,   211268k used,   840980k free,    70504k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                          
 2221 root      25   0  157m 136m 2796 R 46.8 27.1   0:41.46 confd.plx                                                                                                                        
 4058 root      14  -1  116m  67m 1252 S 50.1 13.5 472:07.79 snort_inline                                                                                                                     
 2279 root      35  19 66084  60m 2852 S  0.0 11.9   0:13.05 gen_inline_repo                                                                                                                  
 3604 postgres  17   0 49728  35m  35m S  0.7  7.1  37:10.64 postgres                                                                                                                         
 2913 postgres  15   0 48948  33m  33m S  0.0  6.7   0:14.45 postgres                                                                                                                         
 2286 postgres  16   0 52348  33m  31m S  0.0  6.7   0:46.16 postgres                                                                                                                         
 2322 postgres  22   0 52168  33m  31m S  0.0  6.6   1:13.95 postgres                                                                                                                         
 2345 wwwrun    16   0 32888  26m 3100 S  0.0  5.3   0:04.00 index.plx                                                                                                                        
 3829 root      15   0 39472  13m 1396 S  0.7  2.6  22:31.60 smtpd.bin

I'm not using any of the proxies except SOCKS.

Thanks,
Barry

BarryG · #13 (**permalink**) 01-02-2009, 03:14 AM

I should mention that the high CPU usage by snort is, I believe, because I am currently copying some large files (via SMB) through bridged interfaces in the firewall.

Barry

BarryG · #14 (**permalink**) 01-02-2009, 05:39 AM

I've shutdown the firewall and added another 512MB, so Astaro is now seeing 900MB...

PostGreSQL is still often using a lot of CPU, even when I'm not trying to look at the accounting page, and I still am unable to successfully load the accounting page. I'm going to open another thread about that.

Do I need to reset the accounting database?
e.g. http://www.astaro.org/astaro-gateway...ing-4-5-g.html

The database doesn't seem very big though... 27MB for the data, but the 'pg_xlog' (WAL logs) directory is 426MB... not sure if that's normal?
A new firewall I built a few days ago has 22MB in 'base' and 33MB in 'pg_xlog'.

Thanks,
Barry

cmt · #15 (**permalink**) 01-02-2009, 08:42 AM

The WAL is running fine (under current settings, it grows up to about 460 MB or so and then starts to re-use files).
The *sql.cache-files are used for the webadmin reporting pages and the inline/exucutive reports. The weekly and monthly executive reports generates a larger cache than the "normal" daily inline reports, so you might want to disable the weekly and monthly executive reports. There will be improvements in 7.400...
Judging from the size of the cache-files your machine is way under-spec'ed for the amount of reporting data you're moving about (try 2 or 4 GB of RAM, and a decent stack of fast hard disks), perhaps you should try to disable accounting or reduce the keeping-time to a few days.

BarryG · #16 (**permalink**) 01-02-2009, 08:55 AM

Thanks CMT... I'll try disabling the exec reports... I already had the monthy and weekly ones turned off though.

As far as more ram and faster disks...
This is my home firewall, and my connection is only 500kbits.
I do admit to having P2P programs running most of the time.

I'm actually planning on getting a smaller & lower-wattage firewall to replace this one (but the CPU will be faster).
If I have to live without accounting, I will, but I must say that Astaro 6's accounting worked great on a PII-500MHz with 384MB RAM.

I've opened another thread about the Accounting report failing to open; I'm getting errors in the httpd.log about it.

Thanks,
Barry

BrucekConvergent · #17 (**permalink**) 01-02-2009, 05:00 PM

I would try disabling accounting, then running the reset routine from the shell as found on this forum (don't remember which thread it was)... I'm guessing something is corrupt somewhere.

BrucekConvergent · #18 (**permalink**) 01-02-2009, 05:01 PM

One other suggestion... backup your configuration, and reload the unit with the latest ISO, then restore... that would definitely reinitialize any databases, etc. that were corrupt.

BarryG · #19 (**permalink**) 01-02-2009, 08:52 PM

Hi Bruce,
I found a thread about resetting accounting at
http://www.astaro.org/astaro-gateway...ing-4-5-g.html

but I'm not sure it's current; it mentions 2007 in the thread.

Thanks,
Barry

BarryG · #20 (**permalink**) 01-03-2009, 07:36 AM

Quote:

Originally Posted by BrucekConvergent

One other suggestion... backup your configuration, and reload the unit with the latest ISO, then restore... that would definitely reinitialize any databases, etc. that were corrupt.

Bruce, I have sort of taken your advice... I've just wiped and installed the 7.380 Beta; so far, the accounting page in reporting is working.

Thanks,
Barry