headers
Nathan Morell | 12 Jul 2003 02:19

problems with gentoo, apache 1.3.27, and mod_log_sql [duh]

i guess this isn't good.

Can't locate API module structure `mod_log_sql' in file 
/etc/apache/extramodules/mod_log_sql.so: /usr/sbin/apache: undefined 
symbol: mod_log_sql
/usr/sbin/apachectl start: httpd could not be started

I'm useing a freshly installed gentoo system, most everything is 
compiled from source, php is working fine, mysql is working fine.. I've 
done everything for the "dso" install, to no avail. I tryed searching on 
google too.. no luck

any help?

__________________________________________________________________
Reminder: to unsubscribe, send email to <majordomo <at> grubbybaby.com>
with the words "unsubscribe mod_log_sql" in the body (w/o quotes).
The module homepage is http://www.grubbybaby.com/mod_log_sql/
Permalink | Reply | 1 comment |
headers
Chris Powell | 15 Jul 2003 19:28

Re: problems with gentoo, apache 1.3.27, and mod_log_sql [duh]

Nathan Morell said:
> Can't locate API module structure `mod_log_sql' in file
> /etc/apache/extramodules/mod_log_sql.so: /usr/sbin/apache: undefined
> symbol: mod_log_sql
> /usr/sbin/apachectl start: httpd could not be started

Nathan,
I'm almost certain that this must be due to a syntax error somewhere in
your httpd.conf file.  I'll be happy to take a look at it if you like;
please reply and attach it so that I can try to find the anomaly.

Regards,
Chris

--

-- 
Chris Powell
chris <at> grubbybaby.com
(206) 783-5104 voice, (815) 461-4456 fax

__________________________________________________________________
Reminder: to unsubscribe, send email to <majordomo <at> grubbybaby.com>
with the words "unsubscribe mod_log_sql" in the body (w/o quotes).
The module homepage is http://www.grubbybaby.com/mod_log_sql/
Permalink | Reply | 0 comments |
headers
Sjon . | 15 Jul 2003 20:25
Picon
Favicon

Re: problems with gentoo, apache 1.3.27, and mod_log_sql [duh]

>Nathan Morell said:
> > Can't locate API module structure `mod_log_sql' in file
> > /etc/apache/extramodules/mod_log_sql.so: /usr/sbin/apache: undefined
> > symbol: mod_log_sql
> > /usr/sbin/apachectl start: httpd could not be started
>
>Nathan,
>I'm almost certain that this must be due to a syntax error somewhere in
>your httpd.conf file.  I'll be happy to take a look at it if you like;
>please reply and attach it so that I can try to find the anomaly.
>
>Regards,
>Chris

Nope, he compiled the .so without the MODULE_VAR_EXPORT
constant, wich appears twice (if I'm not mistaken) in the
mod_log_sql.c file...

module MODULE_VAR_EXPORT mod_log_sql;

instead of

module mod_log_sql;

or equivalent...

Sjon.

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Chvostek | 16 Jul 2003 16:48
Picon
Favicon

single table for all vhosts?

Hiya.

Given the apparant lack of list archives for this list, I'm afraid that
as a new user I may be repeating old questions, but anyway ...

Should I expect problems if I set every virtualhost to record log
entries to the same table, rather than create a new table for each
virtualhost?  And is there a way to set that table name *once* rather
than include a "LogSQLTransferLogTable access_log" in every vhost?

I currently have several hundred virtualhosts (and expect it to grow to
several thousand shortly), and this is my first foray into mod_log_sql.
My current (home-grown) control panel software will of course need to
have its functionality extended to support whatever structure I use, and
the major thing I'm thinking will be easier to handle in a single-table
environment is aging and expiry.  I should be able to get all the speed
I need with an index on (virtual_host, time_stamp), so I'm wondering
what the down side is to going this route.

Cancellations would shift from "DROP TABLE www_www_example_com" to
"DELETE FROM access_log WHERE virtual_host='www.example.com'".

Thoughts?

--

-- 
  Paul Chvostek                                             <paul <at> it.ca>
  Operations / Abuse / Whatever
  it.canada, hosting and development                   http://www.it.ca/

__________________________________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Chvostek | 16 Jul 2003 16:55
Picon
Favicon

aging method

And on the topic of aging, what are some strategies for this?

When storing 'combined' to a file with CustomLog, I run a script that
(daily, weekly or monthly depending on site traffic) renames the log
file using standard syslog naming and compresses it with bzip2.  With
this much compression, I don't have a problem storing scads of old data
(in case the user decides to switch log analysis programs), but I will
obviously not be able to bzip2 mysql table records.

Is the solution simply to buy a bigger hard disk, or have folks
developed strategies for moving less-frequently-used to elsewhere?

(I could always just take old data, save it to a file in 'combined'
format and bzip2 it, but ... well, maybe that's the solution.)

--

-- 
  Paul Chvostek                                             <paul <at> it.ca>
  Operations / Abuse / Whatever
  it.canada, hosting and development                   http://www.it.ca/

__________________________________________________________________
Reminder: to unsubscribe, send email to <majordomo <at> grubbybaby.com>
with the words "unsubscribe mod_log_sql" in the body (w/o quotes).
The module homepage is http://www.grubbybaby.com/mod_log_sql/
Permalink | Reply | 1 comment |
headers
Shawn Michael | 16 Jul 2003 21:04
Favicon

Re: aging method

I'll try to answer both of your posts in this one.  

We run mod_log_sql in our production environment so my recommendations are based on experiences we have
had dealing with just under 2 million hits a day being recorded to a single database.

1) For all of this I am assuming that you are using MySQL as a database back end.

2) Use one single access_log table.  If you ever plan on getting over 100,000 hits a day I would say it's
manditory that you use InnoDB due to table locking issues.  If you use MyISAM and multiple tables you will
experience lots and lots of overhead as MySQL opens and closes file descriptors.  Even if you set the number
of allowed file descriptors in MySQL to a high value you will eventually exceed this limit as you add more
hosts.  I think InnoDB may even suffer from this in a slightly diminished capacity.

3) Keep about 5 days worth of data in your main access_log table.  This will cover long weekends with a little
room to spare.

4) Archive off the data from your main access_log to able to something like access_log_20030716.  This
table should be a MyISAM format table.  We do this from 00:00:00  to 23:59:59 GMT for each day.  Once you have
determined that all of the data from a specific day has been inserted into it's table then run myisampack on
the the MyISAM table you just finished creating. (Please refer to the mysql.com site for this as it's
fairly complicated to get correct on a Linux system due to some lack of file locking on that environment). 
We also run a cron job that archives off the data to the access_log_DATE once a minute.  Be sure you have some
scheme of making sure that the web servers have written all of their data to the database server before
doing this.  We have a scheme involving a seperate table that we keep track of time stamps for different web
servers and their last updates.

Archiving is as simple as:
"CREATE TABLE acces_log_DATE blah blah... TYPE=MyISAM" once a day

and from cron every minute (with appropriate checks to make sure you have all of the data):
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Powell | 22 Jul 2003 19:22

Announce: 1.19b1 -- new features!


I'd like to announce a beta release of 1.19, which incorporates a slew of new 
features.  To offer a 'pre-release' in this fashion is a little unusual for 
me.  In this case I need testing assistance, mainly because I'm moving the 
package to GNU autoconf.  

I am *especially* eager to hear from non-Linux folks whether using 
"./configure; make dso; make dsoinstall" works for them.  I need to tweak the 
routines for BSD, Digital Unix, Solaris, etc.  If you are running one of 
these platforms, I would be grateful for your assistance in tuning autoconf 
for your platform -- as always, I happily provide full attribution for your 
help.

New features in 1.19 (so far):
----------------------------------
* Hostnames are now converted to lowercase in the mass-virtual naming section.
  The loop that converts dots to underscores has been optimized as well.
* Migration to autoconf
* New directive LogSQLTableType allows one to specify the kind of table that
  the module makes during table creation (e.g. InnoDB, MyISAM).  Thanks to Jim
  Turner for the suggestion and patch.  If your MySQL server does not support
  the specified type, it will create a MyISAM table instead.
* Directives can now be placed in the 'main' server config and will be
  inherited by the virtual hosts.  This means a LOT less repetition: you only
  specify the item once to have it inherited, but it can still be overridden
  on a virtualhost level.  These can be specified in this manner:

                LogSQLTransferLogTable
                LogSQLTransferLogFormat
                LogSQLPreserveFile
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tom Wiebe Lists | 22 Jul 2003 19:43

Re: Announce: 1.19b1 -- new features!

Looks excellent. I'll be installing in FreeBSD and MacOS X in the next 
several day, I'll let you know how it goes.

One thing that would be really nice, if possible, would be a way to 
specify which fields should be indexed when using 
LOGSQLMASSVIRTUALHOSTING.

Unless it's already there and I've missed it.

Tom Wiebe

On Tuesday, July 22, 2003, at 10:22  AM, Chris Powell wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'd like to announce a beta release of 1.19, which incorporates a slew 
> of new
> features.  To offer a 'pre-release' in this fashion is a little 
> unusual for
> me.  In this case I need testing assistance, mainly because I'm moving 
> the
> package to GNU autoconf.
>
> I am *especially* eager to hear from non-Linux folks whether using
> "./configure; make dso; make dsoinstall" works for them.  I need to 
> tweak the
> routines for BSD, Digital Unix, Solaris, etc.  If you are running one 
> of
> these platforms, I would be grateful for your assistance in tuning
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Powell | 28 Jul 2003 21:16

Re: single table for all vhosts?

Paul Chvostek said:
> Hiya.
>
> Given the apparant lack of list archives for this list, I'm afraid that
> as a new user I may be repeating old questions, but anyway ...

Hello, Paul.  I apologize for a very tardy reply.

There are in fact archives of the list, and I've just updated the message
footer to reflect this.  They can be found here:

http://news.gmane.org/thread.php?group=gmane.comp.apache.mod-log-sql

> Should I expect problems if I set every virtualhost to record log
> entries to the same table, rather than create a new table for each
> virtualhost?  And is there a way to set that table name *once* rather
> than include a "LogSQLTransferLogTable access_log" in every vhost?

This is the way I do it, and it is certainly feasible; I like it because
it means a single, monolithic, convenient table.  (I encourage rebuttal
from folks hosting large numbers of virtualhosts...there might be
situations where one-table-per-host is more appropriate.)

The current functionality of the LogSQLMassVirtualHosting directive is to
activate one table per host.  If you want to log all your virtual hosts to
a single table, simply use LogSQLCreateTables On but skip LogSQLMVH.

As to your second note, I'm pleased that this is a feature in the 1.19b1
release that I put out a few days ago.  That feature was long coming and
is highly appropriate for folks with a setup like yours.  I highly
(Continue reading)

Permalink | Reply | 0 comments |

Gmane