Rejecting message/partial?

[Martin Schulze]

Hi,

Section 5.2.2.1 of RFC2046[1] describes "Message Fragmentation and
Reassembly".  This technique may be used to deliver large files through
the Internet without delivering them in one large mail.  For example,
sending a 3MB large picture could be splitted into three 1MB chunks.

Research has shown that this technique only seems to be supported by
Outlook Express, though.

Unfortunately, this technique could be used to bypass mail filters
since the message containing offending content would be splitted up
into more parts, which aren't normally reassembled on the filter
host.

Do you feel it would be good for mail filters to reject all such
messages?  I.e. reject all parts of partial messages?

 1. http://www.ietf.org/rfc/rfc2046.txt

Regards,

Joey

-- 
Experience is something you don't get until just after you need it.

Please always Cc to me when replying to me on the lists.

Re: RCS control for config files

[Martin Schulze]

Alex Borges wrote:
> Ive finnaly come to a point where i think im needing revision control
> for my configuration files on some servers 

I passed that point already...

> So i thought id come in and ask you guys if there is some vertical stuff
> explicitly for this purpose or if you yourselves simply cvs ci your /etc
> directory et all..

For two remote servers, one of them is maintained by a group of three
people currently, we decided to use CVS and some scripts for
configuring the systems.

The configuration for one of these systems is online at

(you can check it out using anonymous CVS as well.)

Let me give a brief description how it works:

 1. It only contains those configuration files that were changed and
differ from the basic Debian installation and its configuration
files.

 2. The configuration file is owned and thus writable by $user.

 3. Via cron and run-parts the cron.daily directory is executed.

 . The first script manages the »cvs update« step

 . Scripts will copy configuration files to their respective
   locations and call other programs (like some make for wml and
   some web pages).

 . Scripts redirect their output to a log file for later error
   detection.

 . The last script checks for errors in log files

 . At some other time, a process runs as root, forcing some
   daemons to reload their configuration file.

 4. This system has the advantage of configuring the system remotely
and with an infinite number of people involved, which is quite
nice.

 5. It has two (three) major drawbacks, though:

 a) Since run-parts runs as $user, the configuration files need to
exist and be owned by $user, otherwise »cp« will blatantly
fail.  (this will be detected by the error detection, though).

 b) Changing the configuration doesn't take place immediately.
This is no problem for me, but may be one for others.
However, you can still manually trigger the update process,
and you could insert hooks into CVS to auto-trigger an update.

 c) Whenever the Debian system is updated and some files'
ownerships are changed.  Postfix is a good candidate to feel
the pain...

Sorry, I guess the description wasn't as brief as expected...

Regards,

Joey

-- 
Life is a lot easier when you have someone to share it with.  -- Sean Perry

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RCS control for config files

[Martin Schulze]

Alex Borges wrote:
> Ive finnaly come to a point where i think im needing revision control
> for my configuration files on some servers 

I passed that point already...

> So i thought id come in and ask you guys if there is some vertical stuff
> explicitly for this purpose or if you yourselves simply cvs ci your /etc
> directory et all..

For two remote servers, one of them is maintained by a group of three
people currently, we decided to use CVS and some scripts for
configuring the systems.

The configuration for one of these systems is online at

(you can check it out using anonymous CVS as well.)

Let me give a brief description how it works:

 1. It only contains those configuration files that were changed and
differ from the basic Debian installation and its configuration
files.

 2. The configuration file is owned and thus writable by $user.

 3. Via cron and run-parts the cron.daily directory is executed.

 . The first script manages the »cvs update« step

 . Scripts will copy configuration files to their respective
   locations and call other programs (like some make for wml and
   some web pages).

 . Scripts redirect their output to a log file for later error
   detection.

 . The last script checks for errors in log files

 . At some other time, a process runs as root, forcing some
   daemons to reload their configuration file.

 4. This system has the advantage of configuring the system remotely
and with an infinite number of people involved, which is quite
nice.

 5. It has two (three) major drawbacks, though:

 a) Since run-parts runs as $user, the configuration files need to
exist and be owned by $user, otherwise »cp« will blatantly
fail.  (this will be detected by the error detection, though).

 b) Changing the configuration doesn't take place immediately.
This is no problem for me, but may be one for others.
However, you can still manually trigger the update process,
and you could insert hooks into CVS to auto-trigger an update.

 c) Whenever the Debian system is updated and some files'
ownerships are changed.  Postfix is a good candidate to feel
the pain...

Sorry, I guess the description wasn't as brief as expected...

Regards,

Joey

-- 
Life is a lot easier when you have someone to share it with.  -- Sean Perry

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: webalizer

[Martin Schulze]

Matt Fair wrote:
> Hello,
> I am using Debian Stable with Webalizer V1.30-04 (Linux 2.2.12) English. 
> I have several websites running on my server using Apache/1.3.9 (Unix), 
> each site with its own config file.  I have a cron to run: webalizer -c 
>  each half hour.  On October 4th one of my sites got about 
> 20,000 hits and now from the 5th on does not record any records.  No 
> daily stats, nothing.  Apache is still recording the transfer logs, and 
> I manually executed webalizer with the config files, and it runs through 
> the correctly, but does not generate any NEW stats, nothing past the 4th.

Maybe this helps?

> -- Notice --
> Older versions of the Webalizer (Ver 1.30 thru 2.00-12) generated timestamps
> in a fashion that, on most platforms, would overflow on October 5, 2001.  The
> result is that statistics are generated up until midnight of October 4th, but
> not after.  This problem does not exist in the current release (V2.01) of
> the Webalizer, which has been available for over a year now.  If you cannot
> upgrade or wish to continue using the older version, there is a patch on our
> ftp site that will extend the usable date range for three more years,
> however
> will prevent logs before 1993 from being processed.  It can be found at:
> ftp://ftp.mrunix.net/pub/webalizer/pre-release/v130-epoch.patch

Regards,

Joey

-- 
It's time to close the windows.

Re: webalizer

[Martin Schulze]

Matt Fair wrote:
> Hello,
> I am using Debian Stable with Webalizer V1.30-04 (Linux 2.2.12) English. 
> I have several websites running on my server using Apache/1.3.9 (Unix), 
> each site with its own config file.  I have a cron to run: webalizer -c 
>  each half hour.  On October 4th one of my sites got about 
> 20,000 hits and now from the 5th on does not record any records.  No 
> daily stats, nothing.  Apache is still recording the transfer logs, and 
> I manually executed webalizer with the config files, and it runs through 
> the correctly, but does not generate any NEW stats, nothing past the 4th.

Maybe this helps?

> -- Notice --
> Older versions of the Webalizer (Ver 1.30 thru 2.00-12) generated timestamps
> in a fashion that, on most platforms, would overflow on October 5, 2001.  The
> result is that statistics are generated up until midnight of October 4th, but
> not after.  This problem does not exist in the current release (V2.01) of
> the Webalizer, which has been available for over a year now.  If you cannot
> upgrade or wish to continue using the older version, there is a patch on our
> ftp site that will extend the usable date range for three more years,
> however
> will prevent logs before 1993 from being processed.  It can be found at:
> ftp://ftp.mrunix.net/pub/webalizer/pre-release/v130-epoch.patch

Regards,

Joey

-- 
It's time to close the windows.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: OK I should have asked for this earlier

[Martin Schulze]

Allen Ahoffman wrote:
> At the risk of asking twice:
> 
> Please someone recommend a web based help-desk type tracking system to me.
> 
> I'd like it to be flexible, stable, and fairly straightforward to setup
> and administer.
> 
> It doesn't have to do everything imaginable, but straightforward trouble
> ticket and tracking functions would be nice.

Check out http://www.infodrom.north.de/ticket/ and
ftp://ftp.geomic.uni-oldenburg.de/pub/people/joey/ticket/

Regards,

Joey

-- 
There are lies, statistics and benchmarks.