Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 20 replies
  • Subscribers 3 subscribers
  • Views 10055 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

Can't login to webmin [7.305]

BarryG
Hi,
I was going to post that I can no longer log into the VPN using the Linux OpenVPN client, however, I now see that I can't login to webmin either.
"Invalid username or password."


1. Is there still a problem with db corruption or whatever which could cause this?

2. would VPN login failures lock my account from webmin?

3. I can login via SSH. What should I do now?

I first noticed the VPN login wasn't working yesterday.

I've been running 7.305 for 28 days. That is also the last time the firewall was rebooted, and it is on a large UPS. 

dmesg shows no errors

kernel logs are empty all this month except for 2 occasions where I power cycled my internal ethernet switch, for which there are the expected link down/link up messages.

httpd.log has nothing unusual



Also, I'm not getting emails about the webmin login failures.

Thanks,
Barry


This thread was automatically locked due to age.
Parents
  • 0
    confd.log during a login attempt: 

    2008:12:25-01:15:10 (none) confd[10320]: id="3106" severity="info" sys="System" sub="confd" name="authentication successful" client="dns-resolver.plx" facility="system" user="system" srcip="127.0.0.1"

    2008:12:25-01:15:10 (none) confd[10320]: id="3100" severity="info" sys="System" sub="confd" name="closing session DtYgFaPkscQkMJhdptGB: logout" client="dns-resolver.plx" facility="system" user="system" srcip="127.0.0.1"

    2008:12:25-01:15:16 (none) confd[10204]: id="3100" severity="info" sys="System" sub="confd" name="logout" client="index.plx" facility="" user="system" srcip="0.0.0.0"

    2008:12:25-01:15:17 (none) confd[10325]: id="310o" severity="warn" sys="System" sub="confd" name="authentication failed" client="index.plx" facility="webadmin" user="barry" srcip="192.168.11.230"

    2008:12:25-01:15:17 (none) confd[10325]: id="3100" severity="warn" sys="System" sub="confd" name="PERM_DENIED (permission denied)" client="index.plx" facility="webadmin" user="anonymous" srcip="192.168.11.230"

    2008:12:25-01:15:17 (none) confd[10325]: id="3100" severity="info" sys="System" sub="confd" name="logout" client="index.plx" facility="webadmin" user="anonymous" srcip="192.168.11.230"
  • 0 in reply to BarryG 
     ll /tmp/

    total 673960

    -rw------- 1 root root     12288 Dec 23 12:43 aua_auth_cache.db

    -rw-r--r-- 1 root root         0 Dec 25 01:15 aua_auth_cache.db.lock

    -rw-r--r-- 1 root root         0 Dec 25 01:15 aua_confd_cache.db.lock

    -rw------- 1 root root  32098548 Dec 25 01:18 confd-debug.log

    -rw------- 1 root root     20480 Dec 25 01:17 dnsresolver.db

    -rw-r--r-- 1 root root         0 Dec 25 01:17 dnsresolver.db.lock

    -rw------- 1 root root     68285 Dec 24 03:03 mdwdebug.log

    -rw------- 1 root root 657244160 Dec 25 01:18 netacc_sql.cache

    drwxr-xr-x 2 root root      4096 Dec 25 00:00 pdk-root
  • 0 in reply to BarryG
    Not sure if I should delete any of those files... they all have a current timestamp.

    deleted mdwdebug.log as it's older, but I still can't login.

    going to try reboot...

    Barry
  • 0 in reply to BarryG
    rebooted. 
    can login to webmin again.
    will try vpn later

    /tmp looks better for now
     ll /tmp
    total 136
    -rw------- 1 root     root     12288 Dec 25 01:27 aua_auth_cache.db
    -rw-r--r-- 1 root     root         0 Dec 25 01:28 aua_auth_cache.db.lock
    -rw------- 1 root     root     12288 Dec 25 01:28 aua_confd_cache.db
    -rw-r--r-- 1 root     root         0 Dec 25 01:28 aua_confd_cache.db.lock
    -rw-r--r-- 1 root     root       196 Dec 25 01:27 auadebug.log
    -rw------- 1 root     root     43098 Dec 25 01:29 confd-debug.log
    -rw-r--r-- 1 root     root         9 Dec 25 01:28 dhcpd-interfaces
    -rw------- 1 root     root     12288 Dec 25 01:28 dnsresolver.db
    -rw-r--r-- 1 root     root         0 Dec 25 01:28 dnsresolver.db.lock
    -rw-r--r-- 1 root     root         0 Dec 25 01:27 dnsresolver.log
    -rw------- 1 root     root     41324 Dec 25 01:28 mdwdebug.log
    drwxr-xr-x 2 root     root      4096 Dec 25 01:27 pdk-root
    -rw------- 1 postgres postgres    77 Dec 25 01:27 postgres.log



    I'm lowering the IPS, PacketFilter, and Accounting settings to "2 weeks" for now; they were set to "1 month".

    Drive is a 20GB, fwiw.

    Barry
  • 0 in reply to BarryG
    FWIW, I'm currently setting up v7 at work; server has 73GB SCSI disks, and a lot more traffic than I have at home. v6 has been working great, but I need to be sure that v7 won't have problems with accounting, etc. I like how I can keep MANY months of accounting data in v6; I'm not sure what I'll be able to do in v7, but it'd be nice to know.

    Thanks,
    Barry
  • 0 in reply to BarryG
    Hi BarryG,

    looking at the Name of the biggest File in /tmp/ i am assuming, that something had gone wrong with the Network Accounting. Maybe it was not able to dump the detail Data in to the SQL Database so the temporary File never shrunk. 

    -rw------- 1 root root 657244160 Dec 25 01:18 netacc_sql.cache


    And on my 80GB Disk the /tmp/ is still only 1.8GB big, so a bigger Disk might have bought you only a few days (depending on when the Problem startet of course...). The /var/log/ is 36GB big, so it should be able to hold some Water. 1 Month of Logfiles consumes 1% here. But being a Home User with v7, i have no Idea how that scales...

    With the v6 at Work i had to dial down the Log Archive to 90 Days, because 1 Year would not fit on the 32GB Log Partition (on a 73GB Disk).The 90 Days consume 25% of /var/log/. On a realy busy Day i get up to 1GB in Logs witch results in a 65MB tgz compressed File in the remote Log Archive.
  • 0 in reply to KSeemann
    My /tmp is 688M, and after 1.7days uptime, the accounting file is at 43MB. 
    Note that I've already lowered my accounting settings to only keep 2 weeks.

    Also, I am now able to login to the VPN again, at least internally [:P]

    Thanks,
    Barry
  • 0 in reply to BarryG
    I think there's still a problem... 

    loginuser@fw:/tmp > uptime

      2:17pm  up 6 days 12:51,  1 user,  load average: 0.67, 0.31, 0.31

    loginuser@fw:/tmp > ll /tmp/

    total 175916

    -rw------- 1 root      root         12288 Dec 25 23:04 aua_auth_cache.db

    -rw-r--r-- 1 root      root             0 Dec 25 23:04 aua_auth_cache.db.lock

    -rw------- 1 root      root         12288 Dec 25 23:04 aua_confd_cache.db

    -rw-r--r-- 1 root      root             0 Dec 25 23:04 aua_confd_cache.db.lock

    -rw-r--r-- 1 root      root           196 Dec 25 01:27 auadebug.log

    -rw------- 1 root      root       7840415 Dec 31 14:17 confd-debug.log

    -rw-r--r-- 1 root      root             9 Dec 25 01:28 dhcpd-interfaces

    -rw------- 1 root      root         20480 Dec 31 14:16 dnsresolver.db

    -rw-r--r-- 1 root      root             0 Dec 31 14:16 dnsresolver.db.lock

    -rw-r--r-- 1 root      root             0 Dec 25 01:27 dnsresolver.log

    -rw-r--r-- 1 root      root             0 Dec 25 22:59 ipsec_status.debug

    -rw------- 1 root      root         49359 Dec 31 02:40 mdwdebug.log

    -rw------- 1 root      root     170545152 Dec 31 14:05 netacc_sql.cache

    -rw-r--r-- 1 root      root             0 Dec 31 14:17 netacc_sql.cache.lock

    drwxr-xr-x 2 root      root          4096 Dec 27 01:15 pdk-root

    -rw------- 1 postgres  postgres        77 Dec 25 01:27 postgres.log

    -rw-r--r-- 1 root      root             0 Dec 25 01:31 reversednsresolver.log

    -rw------- 1 root      root       1445888 Dec 31 14:17 sql.cache

    -rw-r--r-- 1 root      root             0 Dec 31 14:17 sql.cache.lock

    drwx------ 2 loginuser users         4096 Dec 31 14:17 ssh-mNvGH27401

    loginuser@fw:/tmp > df -h

    Filesystem            Size  Used Avail Use% Mounted on

    rootfs                5.3G  1.1G  4.0G  22% /

    udev                  253M   60K  252M   1% /dev

    /dev/disk/by-label/root

                          5.3G  1.1G  4.0G  22% /

    /dev/disk/by-label/boot

                          342M   14M  311M   5% /boot

    /dev/disk/by-label/storage

                          4.3G  754M  3.3G  19% /var/storage

    /dev/disk/by-label/log

                          5.6G  2.1G  3.3G  40% /var/log


    Still running 7.305, btw.
  • 0 in reply to BarryG
    I haven't really seen any problems like this at any sites... is this a new config, or one you converted from V6?

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Reply
  • 0 in reply to BarryG
    I haven't really seen any problems like this at any sites... is this a new config, or one you converted from V6?

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Children
  • 0 in reply to BrucekConvergent
    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:

    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.
  • 0 in reply to LewisRosenthal
    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: 
    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
  • 0 in reply to BarryG
    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
  • 0 in reply to BarryG
    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. https://community.sophos.com/products/unified-threat-management/astaroorg/f/51/t/20299

    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
  • 0 in reply to BarryG
    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.
  • 0 in reply to cmt
    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
  • 0 in reply to BarryG
    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.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to 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.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    Hi Bruce,
    I found a thread about resetting accounting at
    https://community.sophos.com/products/unified-threat-management/astaroorg/f/51/t/20299

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

    Thanks,
    Barry
  • 0 in reply to 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
Unfiltered HTML