[Interface] Permissions to write to /var/log/ispconfig

Discussion in 'Developers' Forum' started by MaddinXx, Aug 14, 2012.

  1. MaddinXx

    MaddinXx Member

    Hi together

    I am currently trying to implement fail2ban compatible logging into SVN but I've some problems.

    My first approach was placing the code into index.php within the login folder.

    Problem: exec() not working (it's clear why).

    Then I tried to create it as a server plugin, however, they are only run if their is an action to do like updating DNS etc. and runs every few minutes (which is not enough).

    So I removed this try and realized, that it has to be done within the interface and not the server (as it belongs to it).

    So now the problem still exists, that the interface is not allowed to run code out of it's space, e.g. in /var/log/ispconfig/.

    What would be the correct way to do this? Would it be possible to use the $app->log "command" and set the LOGLEVEL to "ERROR" or is there another recommended way of doing this?

    //edit: LOGLEVEL error wouldn't be the best choice I guess, because the log gets kind of spammed without real errors...

    //edit2: realized that $app->log only logs to MySQL by default so this doesn't help. It seems like the only change is to create a cron running all few seconds to fetch entries from DB and write to file..

    Thank you very much!
    Michel
     
    Last edited: Aug 14, 2012
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    ISPConfig contains already a mechanism that blocks users automatically after a few logins, so what fail2ban does is already implemented in ISPConfig.

    If you want to add a log file for denied logins to block on network level as well, then add code to the file /usr/local/ispconfig/interface/web/login/index.php in the same place where the internal ispconfig lock mechanism is implemented, you have to add just a simple fwrite to your log file in that place. Use /var/log/ispconfig/auth.log as log file name, ensure that this file is created in the installer with touch() and chowned to user and group ispconfig, otherwise you cant write to that file. You might want to log the successfull logins as well to that log. The third thing that would have to be implemented is a log rotation similar to the one of the cron.log in the cron_daily.php file in ispconfig.

    Please dont use any exec, passthrus etc. commands in the interface.

    PLease dont add a separate cronjob or server plugin or similar solution.
     
  3. MaddinXx

    MaddinXx Member

    Hi till

    Thank you! I think I've managed it with your words help!
     
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    Thanks! :)

    Maybe you might add a little optimisation to the code, currently the log file is world writable. It would be better if you add code to the installer that does a chown and chgrp on the log file to user and group "ispconfig" and then change the chmod so that only user and group can write to the file.
     
  5. MaddinXx

    MaddinXx Member

    Hi till

    I've pushed my latest changes to SVN, I hope it's right now (especially the chmod 660).
     
  6. cfoe

    cfoe ISPConfig Developer ISPConfig Developer

    I installed a dev machine with 4.0.4.6 + update to SVN $3388 (i think)

    auth.log was not created.
    Can anyone second that?
     
  7. MaddinXx

    MaddinXx Member

    Hi cfoe

    If you did not install directly from SVN, this can more than be since I didn't do anything within the updater since I did not know how the updater is "compiled" e.g. what are the criteria to add things in there.

    Will add this.
     
  8. Croydon

    Croydon ISPConfig Developer ISPConfig Developer

    I updated to latest SVN and have got an auth.log.
    But I don't know if it was created during update or installation earlier.
    Anyway - it is owned by root, not writable by the interface and has a date of Jan, 1st 1970.
     
  9. till

    till Super Moderator Staff Member ISPConfig Developer

    I had the same problem here. I deleted the file and rerun the update and the file was created with correct permissions. So I gues sthe issue has been fixed in the meantime (last update on 16.).
     
  10. Croydon

    Croydon ISPConfig Developer ISPConfig Developer

    Maybe the updater should be extended to correct wrong permissions on existing file, too?
     
  11. cfoe

    cfoe ISPConfig Developer ISPConfig Developer

    An update which fixes and not breaks -- something new. sweet
     

Share This Page