So I've seen the commercials on TV about GoToMeeting for a while, but I never had a opportunity to try it out. Yesterday, I had a conference call with a web client about a application we're developing and going over some server requirements to pull it off. Early in the call, the client recommend that we have this meeting using GoToMeeting, since there were some graphic design topics that they needed to discuss with me and a marketing director.
My first time with GoToMeeting
Recent package updates are making me nervous (Snort and Mod_Security)
A few weeks ago, I saw that snort needs to update to 2.8.4.1 (up from 2.6.1.3-r1), but with this update, it no longer has support for snortsam. This sucks! I posted a thread about this on the Gentoo forums, but no response yet. Because of this I'm not updating my production boxes, that use snortsam as part of it's IPS. On a box that was running just snort, I had troubles getting it started. The whole thing left a unpleasant taste in my mouth.
Here are some relevant links about this:
http://forums.gentoo.org/viewtopic-t-764081-highlight-snort.html
http://bugs.gentoo.org/245752
Good site, admin
I started seeing emails posted via contact forms with this message body. All sites on multiple servers starting experiencing this. I believe this is just a probe to test if contact forms are requiring captcha or this could be a initial set up for backscatter, etc. Either way, I don't like it. The first piece of investigation was to look at the IP of the originating requests. Unfortunately, they're all random. Clearly the program is using a proxy, or this could be a virus/worm related activity. So blocking based on origin is not a good solution.
The next route that made the most sense for me was to create a mod_security rule to block this traffic based on POST payload. I'm running mod_security-2.1.2, so this rule may not work depending on what brand of mod_sec you're running. I created the following rule in my custom rule config.
How to set up Spamassasin-FuzzyOcr for Gentoo
After seeing a increase in image spam, I decided to add the Fuzzy OCR plugin for spamassassin. Basically, it will read the image and see if there are any words or phrases that are labeled as spam and append a score to it. I was surprised that I didn't see any how tos for Gentoo, and I ran across multiple issues setting this up, so here we go.
We need to use spamassassin-fuzzyocr-3.5.1-r1 to get things working. Currently, Gentoo has 2.3b as the stable version, make sure you use the latest greatest. I added the following to /etc/portage/package.keywords:
=mail-filter/spamassassin-fuzzyocr-3.5.1-r1 ~x86
dev-perl/MLDBM-Sync ~x86I added the following USE flags to /etc/portage/package.use
media-libs/netpbm jpeg jpeg2k png tiff xml zlib -jbig -rle -svga
mail-filter/spamassassin-fuzzyocr amavis dbm gocr logrotate mysql ocrad tesseract
app-text/tesseract tiffGrep the line and the line before or after.
Here is a sweet trick I learned to day to grab the line you're looking for as well as the line after or before. It's using the -A or -B flag within grep. Glad I found this before writing a stupid script using awk, etc.
grep 'some value in a line' -B 1 /var/log/messagesThis will grab the line and one line before. Use -A NUM for after the target.
Dealing with Qmail's TAI64N format
Today I had to do some work on my qmail, which I hate to work with. Basically, I needed to go through the logs and and verify some deliveries, etc. Well, the timestamps for qmail is using TAI64N (which I just learned about). You can use tai64nlocal to convert them to readable timestamps. Again, this is mostly for my reference in case I need to do this again.
Potential DNS DDoS (query (cache) './NS/IN' denied)
I started getting a ton of these in my DNS logs a few days ago:
Jan 19 05:33:47 comp named[4488]: client 76.9.31.42#55056: query (cache) './NS/IN' denied
Jan 19 05:33:53 comp named[4488]: client 76.9.31.42#30931: query (cache) './NS/IN' denied
Jan 19 05:33:59 comp named[4488]: client 76.9.31.42#31789: query (cache) './NS/IN' denied
Jan 19 05:34:06 comp named[4488]: client 76.9.31.42#38458: query (cache) './NS/IN' denied
Jan 19 05:34:12 comp named[4488]: client 76.9.31.42#31734: query (cache) './NS/IN' denied
Jan 19 05:34:18 comp named[4488]: client 76.9.31.42#52640: query (cache) './NS/IN' denied
Jan 19 05:34:24 comp named[4488]: client 76.9.31.42#12441: query (cache) './NS/IN' denied
Jan 19 05:34:30 comp named[4488]: client 76.9.31.42#20453: query (cache) './NS/IN' deniedApache-2.2.10 / Chroot and cURL is giving me some grief (SOLVED)
So my woes with Apache-2.2.10 and chroot is continuing. Now I can start Apache in the chroot environment, and I thought all was well, but after additional testing, I found out that cURL does not work. Basically, cURL will return a empty string while it's chroot'd. This is very weird to me, since the jail is EXACTLY the same as it was when mod_chroot was set up initially. This would mean the libraries should all be good still. I tested with the apache out of the jail and cURL works great. I've seen multiple mention of this problems, but usually related to https requests while in the jail. I've encountered those in the past (usually related to certs, urandom, etc missing from the jail). This problem is with straight http requests. I did find one very similar post here: http://kerneltrap.org/mailarchive/openbsd-misc/2007/3/21/146482/thread.
Use mysqldump to get single table
Hello all, this is primarily so I don't forget how to do this in the future. I needed to get a dump of a single table out of a remote database. This is the mysqldump command to pull that off:
mysqldump -p --user user databaseName tableName > out.sqlApache-2.2.10 and mod_chroot-0.5 - Issue is solved
I have it figured out! This is originally referencing the trouble I was having starting apache-2.2.10 and using mod_chroot-0.5 (http://www.uno-code.com/?q=node/155). You cannot use mod_chroot with apache-2.2.10. Apache-2.2.10 because apache has built in chroot support now.
http://httpd.apache.org/docs/2.2/mod/mpm_common.html
All you need to do is provide a ChrootDir variable in httpd.conf. The problem is that mod_chroot sets that value as well, I think it was trying to do a "double" chroot. Removing the -D chroot flag from /etc/conf.d/apache2 flags and configuring the variable got the server to start, and I verified that the chroot jail was working. What I'm mostly surprised with is that nobody seemed to have this problem. No follow up posts in the forum, and the bug is getting no activity.
I'll close the bug and state the issue is solved in the forum.
Hope this helps someone out there.. it was a pain to get to the bottom of it.
hanji

Recent comments
38 weeks 1 day ago
38 weeks 6 days ago
42 weeks 2 days ago
42 weeks 2 days ago
1 year 6 weeks ago
1 year 14 weeks ago
1 year 21 weeks ago
1 year 25 weeks ago
1 year 32 weeks ago
1 year 33 weeks ago