The new version of Baruwa is out version 1.0.2 As there are still some functions broken in the 1.0.1 I'd like to upgrade. But in the howto custom versions where included so just doing a dpkg -i doesn't work with the new packages. How can I upgrade to the newest version ? And question 2, the fuzzy-cleanmysql cronjob doesn't work it gives a 100% cpu load but does nothing and keeps running forever until you kill it. All configuration parameters where entered correctly. Anyone having it working ?
I would also like to know howto upgrade Baruwa to the latest version Regarding the /usr/sbin/fuzzy-cleanmysql script, I'm also having 100% cpu usage and it doesn't seem to complete it.
I think I have the recipe now Prerequisites: 1) Backup /usr/share/pyshared/baruwa/settings.py 2) Follow below #cd /usr/src #rm baruwa-doc_1.0.1-1_all.deb baruwa_1.0.1-1_all.deb # wget http://topdog-software.com/oss/baruwa/1.0.2/deb/baruwa_1.0.2-1_all.deb #wget http://topdog-software.com/oss/baruwa/1.0.2/deb/baruwa-doc_1.0.2-1_all.deb #gdebi baruwa*.deb <- SELECT NO TO DATABASE CONFIG!! #reboot #cd /usr/src/ #ln -s /opt/MailScanner-4.81.4-1/ /opt/MailScanner #./mailscanner.sh #/etc/init.d/mailscanner start #/etc/init.d/postfix start 3) Copy your backed up "settings.py" to /usr/share/pyshared/baruwa 4) Reboot (might not be neccesary) 5) Profit? Disclaimer: This worked for me, but I do NOT guarantee it will work for you! EDIT: Functions such as deleting an "Auth server" from a domain, still causes errors, but the AJAX errors seems to be solved. Code: AttributeError at /settings/auth/2/delete/ 'NoneType' object has no attribute 'widget' Request Method: POST Request URL: http://mailgw.domain.tld/settings/auth/2/delete/ Django Version: 1.2.3 Exception Type: AttributeError Exception Value: 'NoneType' object has no attribute 'widget' Exception Location: /usr/lib/pymodules/python2.6/django/forms/forms.py in _clean_fields, line 278 Python Executable: Python Version: 2.6.6 Python Path: ['.', '', '/usr/lib/python2.6', '/usr/lib/python2.6/plat-linux2', '/usr/lib/python2.6/lib-tk', '/usr/lib/python2.6/lib-old', '/usr/lib/python2.6/lib-dynload', '/usr/local/lib/python2.6/dist-packages', '/usr/lib/python2.6/dist-packages', '/usr/lib/python2.6/dist-packages/PIL', '/usr/lib/pymodules/python2.6', '/usr/lib/pymodules/python2.6/gtk-2.0'] Server time: Tue, 22 Feb 2011 15:13:49 -0500
Why don't you guys just follow the upgrade section of the howto guide? It's right below the installation of Baruwa section. I'll check out the fuzzy script.
Thanks a lot Rocky! I couldn't get it to work by following the upgrade instruction in the How-To, therefore I made above "fix"
Besides the fact that I didn't see the upgrade part untill now I would like to be able to keep the install updated myself... This howto won't be updated forever....
Just a note to all, you do not really need the doc package for a functional system it just contains the documentation.
Andrew thanks, I did realize that but you know how the copy and paste effect goes, if it's there, just leave it..lol Laziness I guess. Jim, If you used Andrew's deb, then the upgrade will not work if you try it with my deb as I've changed a few things from the original. I've been able to upgrade all of my installs using the guide. Normanu, It's always good to know how to do it yourself.
Thanks Rocky, but for some odd reason the .deb install of Andrew's .deb files worked flawlessly, but of course I don't know where to check for errors hehe. But at least it fixed the AJAX Java problems when releasing from quarantine/deleting/sa-learning etc. Anyway I can check that the system is tip-top without degrading my system?? Thank you.
Hmm, I haven't used Andrews deb for an upgrade, but I'm sure since it's not really altering anything outside of Baruwa, it should be fine. However, if it was used in a fresh install scenario with the snake, I assume it would cause some probs with it's dependencies. Just check your log files(mail, uswgi, nginx), if no errors are apparent and mail is being scanner/relayed, then I would say you are good to go. Make sure to read the postfix section carefully to really understand the addons, because some things cannot be used with others.
Thanks Rocky. Nginx seems clear apart from this: Code: 200.46.83.245 - - [23/Feb/2011:16:31:39 +0100] "GET /w00tw00t.at.ISC.SANS.test0:) HTTP/1.1" 400 172 "-" "-" Mail.log looks fine uwsgi.log contains a lot of these: Code: Wed Feb 23 08:36:15 2011 - SIGINT/SIGQUIT received...killing workers... Wed Feb 23 08:36:16 2011 - goodbye to uWSGI. Wed Feb 23 08:37:05 2011 - [uWSGI] getting YAML configuration from /etc/uwsgi/uwsgi-python2.6/baruwa.ini Wed Feb 23 08:37:05 2011 - *** Starting uWSGI 0.9.6.6 (32bit) on [Wed Feb 23 08:37:05 2011] *** Wed Feb 23 08:37:05 2011 - compiled with version: 4.4.5 Wed Feb 23 08:37:05 2011 - Python version: 2.6.6 (r266:84292, Sep 15 2010, 16:02:57) [GCC 4.4.5] Wed Feb 23 08:37:05 2011 - writing pidfile to /var/run/uwsgi/uwsgi-python2.6/baruwa/pid Wed Feb 23 08:37:05 2011 - uWSGI running as root, you can use --uid/--gid/--chroot options Wed Feb 23 08:37:05 2011 - setgid() to 33 Wed Feb 23 08:37:05 2011 - setuid() to 33 Wed Feb 23 08:37:05 2011 - your memory page size is 4096 bytes Wed Feb 23 08:37:05 2011 - allocated 416 bytes (0 KB) for 1 request's buffer. Wed Feb 23 08:37:05 2011 - binding on UNIX socket: /var/run/uwsgi/uwsgi-python2.6/baruwa/baruwa.sock Wed Feb 23 08:37:05 2011 - your server socket listen backlog is limited to 64 connections Wed Feb 23 08:37:05 2011 - initializing hooks...Wed Feb 23 08:37:05 2011 - done. Wed Feb 23 08:37:05 2011 - application 0 () ready Wed Feb 23 08:37:05 2011 - setting default application to 0 Wed Feb 23 08:37:05 2011 - spawned uWSGI master process (pid: 1843) Wed Feb 23 08:37:05 2011 - max_ovec = 0 Wed Feb 23 08:37:05 2011 - spawned uWSGI worker 1 (pid: 1850) Wed Feb 23 08:37:05 2011 - spawned uWSGI worker 2 (pid: 1851) Wed Feb 23 08:37:42 2011 - routing 0 routes 0 [pid: 1850|app: 0|req: 1/1] 80.87.90.14 () {28 vars in 335 bytes} [Wed Feb 23 02:37:42 2011] GET /webdav/test => generated 2259 bytes in 104 msecs (HTTP/1.1 404) 1 headers in 51 bytes (0 async switches on async core 0) Wed Feb 23 08:37:56 2011 - routing 0 routes 0 [pid: 1851|app: 0|req: 1/2] 193.219.27.230 () {48 vars in 903 bytes} [Wed Feb 23 02:37:56 2011] GET /messages/ => generated 146 bytes in 347 msecs (HTTP/1.1 200) 2 headers in 71 bytes (0 async switches on async core 0) Wed Feb 23 02:38:47 2011 - routing 0 routes 0 [pid: 1850|app: 0|req: 2/3] 193.219.27.230 () {42 vars in 773 bytes} [Wed Feb 23 02:38:47 2011] GET / => generated 3390 bytes in 382 msecs (HTTP/1.1 200) 5 headers in 219 bytes (0 async switches on async core 0) Wed Feb 23 02:38:47 2011 - routing 0 routes 0 [pid: 1851|app: 0|req: 2/4] 193.219.27.230 () {44 vars in 772 bytes} [Wed Feb 23 02:38:47 2011] GET /jsi18n/ => generated 667 bytes in 5 msecs (HTTP/1.1 200) 4 headers in 118 bytes (0 async switches on async core 0) Wed Feb 23 02:38:53 2011 - routing 0 routes 0 [pid: 1850|app: 0|req: 3/5] 193.219.27.230 () {44 vars in 836 bytes} [Wed Feb 23 02:38:53 2011] GET /settings/ => generated 2064 bytes in 146 msecs (HTTP/1.1 200) 5 headers in 219 bytes (0 async switches on async core 0) Wed Feb 23 02:38:53 2011 - routing 0 routes 0 [pid: 1851|app: 0|req: 3/6] 193.219.27.230 () {44 vars in 781 bytes} [Wed Feb 23 02:38:53 2011] GET /jsi18n/ => generated 667 bytes in 1 msecs (HTTP/1.1 200) 4 headers in 118 bytes (0 async switches on async core 0) Wed Feb 23 02:38:55 2011 - routing 0 routes 0 [pid: 1850|app: 0|req: 4/7] 193.219.27.230 () {44 vars in 865 bytes} [Wed Feb 23 02:38:55 2011] GET /settings/domains/2/ => generated 2084 bytes in 103 msecs (HTTP/1.1 200) 5 headers in 219 bytes (0 async switches on async core 0) Wed Feb 23 02:38:55 2011 - routing 0 routes 0 By "postfix section" do you mean of your guide?
Yes, I meant the guide. This is what I got for researching nginx: What is GET /w00tw00t.at.ISC.SANS.DFind HTTP/1.1? A record of "GET /w00tw00t.at.ISC.SANS.DFind HTTP/1.1" in your Raw Access logs indicates that someone has been hacking at your web site! By itself, this entry does not mean that you have been hacked. It only means that someone has been trying to hack your site. The entry should always have caused a "400" error on your site, indicating that the attempt was unsuccessful. This entry should send you a message. Keep your code clean! Most web sites are attacked in one way or another almost every day. Your best defense is to learn what you can do to keep your files, directories, and scripts safe from hackers. Be sure you have your file and directory permissions set properly. Even more imortantly, only use safe scripts that have a good reputation for security on the Internet, and be sure that you always check the parent sites for your scripts at least once a month for updates and bug fixes. Hope that helps.
Excellent, thank you very much. The only thing running on that is Baruwa. I think I'll use my "well tested" IPTables script as firewall in stead.
