Results 1 to 8 of 8

Thread: Where o' where is the syslog.log???

  1. #1

    Where o' where is the syslog.log???

    Been trying to find this flirking file all evening. The web GUI can access it so it exists somewhere right? If it's only accessible via ram and not in file format, can the export syslogs (from within the GUI) be pointed back to the device itself and have a second syslogger running (syslogd is running already) to parse the logs into a physical log file?

    I need this so that I can parse the log to strip out failed logins to ban the IP's from brute force attacks.

    Any help is well... helpful.

  2. #2
    you could setup a cron job, to parse the log to a file on a given interval.

    'logread' outputs the log to the terminal. To parse it to a file type:

    '/sbin/logread >> /opt/etc/log.txt'
    /regards
    Henrik

  3. #3
    I agree, I could make a cron job to spit out the logread contents to a .txt file every minute but then that would negate the HDD spindown feature as the drive would get hit every minute. Is there any other way to poll the syslog contents? like in vram or something like that? Basically is syslogd only holding the syslog contents in the circular buffer (in ram I'm guessing) or is it also writing it to a ramdisk file in another location and constantly updating it?

  4. #4
    why not just output it once a day?...........
    /regards
    Henrik

  5. #5
    I'm going to use the syslog output to feed fail2ban to thwart brute force attacks on the vsftpd server (getting hammered).

    Is there a way to output logread to a virtual file eg one in ram that mimics a physical file and thus would not cause the HDD to spin up when getting written??? That way fail2ban would have a log "file" to access and the cron job would merrily update every minute and not hit the hard drive and then the spindown would work again???

  6. #6
    Drop your logread output in /tmp. It's a ram filesystem and accessing it shouldn't spin up with your HDD.

    - K.C.

  7. #7
    i have edited the rc.local to kill the existing syslogd (killall syslogd) and then launch syslogd with the parameter of logging to a file on the hard disk (i have created mine on /shares/MYVOLUME1/messages ; i _don't_ want the hard drive to spin down, the more you mechanically stress the drive, the sooner it will die; and even worst, the hard drives in wl700 are hitachi ones and i remember a lot of ibm deskstar suddenly dying: hitachi is now the former ibm's hard drives division)

    i don't remember the syslog flag and can't find it neither in my linux workstation syslogd man page; i'll post the syslog flag when i come home from work (or try syslogd -h on the asus machine).

    don't know what existing 'syslog -R 255.255.255.255' does, does not seem to be documented
    Last edited by costinel; 15-01-2007 at 08:47.

  8. #8
    Quote Originally Posted by kfurge View Post
    Drop your logread output in /tmp. It's a ram filesystem and accessing it shouldn't spin up with your HDD.

    - K.C.
    Huh, didn't know we could access /tmp. Anyway, before I read your post, I made a ramfs mount on my own using:

    mount -t ramfs ramfs /shares/MYVOLUME1/rmd -o size=1m

    I did a mkdir for /rmd prior to the mount statement. The result worked, the cron job dumped the log contents to a text file in a ramdisk and the hard drive never spun up...

    Here are the new issues (one hopefully fixable the other will take some time methinks).

    1) Whenever the cron job completes it puts an entry into the syslog. This will eventually fill the syslog with completed events every minute. Is there a way to silence the logging of cron? I tried the > /dev/null option but it didn't seem to care (as this trails the cmd for outputting the logread to the txt file). I was thinking of having the cron job call a script instead of logread directly and then have the cron job output > /dev/null. Any thoughts on this?

    2) fail2ban detects the overwrite of the txt file and pins to the end of the file but doesn't re-read it (nor is it parsing correctly)... Guess I gotta go to the original programmers for that one...

    Sooo close....

    Ironically, no brute force attacks today yet.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •