Log Files automatisch legen

[nielsje]

Ik heb een webserver met redhat Linux,
mijn logfiles lopen om de twee dagen vol.
Als ik deze niet leeg zou de server crashen.

Alleen vroeg mij af of dit niet makkelijker kan,
bijvoorbeeld door een script die deze elke avond om 12 uur leegt.

ook heb ik problemen met mijn sendmail kan dit er ook mee te maken?
Deze doet het namelijk alleen op minder drukke tijden

alvast bedankt
Niels

[Dennis]

Dit kan met logrotate d8 ik
Je kunt ook installen dat hij niet logt (2 dagen loggen is wel vrij weinig)
In plesk is dit o.a. makkelijk in te stellen

[nielsje]

Origineel geplaatst door DennisCitus
Dit kan met logrotate d8 ik
Je kunt ook installen dat hij niet logt (2 dagen loggen is wel vrij weinig)
In plesk is dit o.a. makkelijk in te stellen

ik heb hier niet veel verstand van,
maar ik heb wel in de httpd.conf de logfiles in de map /content/map/logs uitgeschakelt,
maar deze slaat hij wel op in var/log/apache/error.log (deze loopt namelijk altijd vol)

ik bestuur mijn server via het programma putty en heb dus geen plesk of een andere webadmin.
en vroeg mij af of er geen scripje voor is om deze logfiles te kunnen weggooien

[wdv]

Origineel geplaatst door nielsje

en vroeg mij af of er geen scripje voor is om deze logfiles te kunnen weggooien

logrotate/newsyslog

[InstantXs]

of zelf een simpel scriptje schrijven en in je crontab zetten

[Raptor]

Iedereen heeft het hier altijd over een contrab maar wat is het aan waar staat hij?

[babak]

Crontab vind je afhankelijk van je OS meestal in /etc

dus; b.v: pico /etc/crontab en je kan wat extra regels erbij zetten.

Hieronder heb je een uitleg over wat crontab doet:
p.s: het is niet van mij



Note: crontab scripts (the actual scripts rather than crontab itself), should always be tested in advance of them running live under crontab (IMHO). As they could bring down the machine in the middle of the night when running and you may not be aware for many hours. I think its better to know when awake


System Schedules /etc/cron.????

Your scripts (if you want to use this method, should be placed in the relevant directory (or a symbolic link) and the ownership/permissions should also be the same as the others that already exist there.)
NOTE: That all the cron directories items (see below) are executed in Alphabetical order, so a script called /etc/cron.daily/abc will be executed before /etc/cron.daily/def.

/etc/cron.daily
/etc/cron.half-hourly
/etc/cron.hourly
/etc/cron.monthly
/etc/cron.quarter-daily
/etc/cron.quarter-hourly
/etc/cron.weekly


User crontab

To use the regular crontab system that is available for ALL users.
IMHO this is a safer way to do things, as the script will be executed as that user and not as the 'root' user.
This way you can allow your customers to use crontab and limit the damage the scripts can do.
You can use regular crontab (type "man crontab" or "man cron" in ssh) and use the default editor (=VI), if your a VI lover.

When the script runs, if it produces any output (STDOUT), this is usually mailed to the user that the script is run under! It would be wise to ensure that this user does actually receive email.

I prefer to use other editors/ftp with a file containing the crontab listings for each user. Here is a quick/easy way to do this, without altering the raqs default crontab editor (vi):

Create a file for the user in question (in this example 'username') - have a seperate file for each user is required.
You may prefer to keep all your crontab files in the respective users home directory... ie /home/sites/home/users/username (dont place them in the users web directory though, because of the potential security risks !!)

pico -w ~/somefilename

And add something like this (to add more, just place each one on its OWN line):

0 11,23 * * * perl /home/sites/home/users/username/the-script.pl

which tells crontab to run the script at 11:00 & 23:00 every day

If you want to setup/install a users crontab whilst logged in as ro

Now you need to update the user ('username' in my example) if you run this as root.

crontab -u username /home/sites/home/users/username/somefilename

You can check to see what they user currently has....

crontab -u username -l

Or if you want to remove **ALL** the crontab entries for the user ('username' in this example)

crontab -u username -r

If you want to let the users setup/install a crontab for themselves whilst logged in via ssh:

The users crontabs will only be affected here, and not any other users (logged in as username here)

crontab ~/somefilename

The user can check to see what they currently have....

crontab -l

Or they can remove **ALL** the crontab entries (this does NOT delete the file used above)

crontab -r


How to discover all the users that have a crontab setup, and what these crontabs are:

To see what users have a crontab set to be executed:

ls -Al /var/spool/cron

will list all the users whom have a crontab

To see their crontab, you can see it one of two main ways:

crontab -u username -l # replace username with the username :-)

or a less preferred way:

cat /var/spool/cron/username # replace username with the username :-)


Whats the format for crontab, and what does it all mean?

A crontab file consists of six fields, each seperated by a space.
The first five fields indicate when the script/program/command is to be run. And the sixth field is the script/program/command itself.

Minutes after the hour (0-59)

Hour, in 24 hour format (0-23)

Day of the month (1-31)

Month (1-12)

Day of the week (0-6; the 0 refers to Sunday)

Asterisks "*" specify when commands are to be run in every instance of the value of the field. ie an asterisk in the day field (3) tells crontab to run every day

Hyphens "-" (inbetween numbers), tells crontab to run this between the start number and end number. ie 5-9 in the month field would tell crontab to run this crontab during May , June, July, August and September (5 - 9 inclusive!).

Commas "," (inbetween numbers), tells crontab to run this on the specific numbers, which allows mutiple schedules. ie 1,2,3,15,16,17 in the Day of the Month field would tell crontab to run this crontab on the 1st and again on 2nd and again on 3rd and again on 15th and again on 16th and finally on the 17th of the month.

Mutiple - and , maybe used to further increase the flexibility of crontab. ie 1-5,7,25-38,31 could be used in the day of the Month field.

Dont forget that a SPACE is the seperator between the 6 above fields, and you should not use it in the first 5 fields!

Some Examples:

To run the commands at 5am every day of every month

0 5 * * * commands

To run the commands at 10am every Friday of every month

0 10 * * 5 commands

To run the commands at 10am every on Sunday and Friday of every month

0 10 * * 0,5 commands

To run the commands at 7:09am on weekdays only of every month

9 7 * * 1-5 commands

To run the commands between 1:00am and 1:59am at one minute intervals on every day of the month

* 1 * * * commands

To run the commands at 1pm on the 5th, 10th, 15th, 20th, 25th, and 30th only of every month (obviously February does not use the one schedule on the 30th)

0 13 5,10,15,20,25,30 * * commands

To run the commands every other month at 9pm

0 21 * 1,3,5,7,9,11 * commands


How do I ban/stop some users from using crontab?

To ban/stop a user from updating/deleting/creating a crontab, you will need to create a file in /etc/ called cron.deny, and ensure the permissions are set to 0600 and is owned by ro

touch /etc/cron.deny
chmod 0600 /etc/cron.deny
chown root.root /etc/cron.deny

In this /etc/cron.deny file you should place a list of ALL users you want banned (each on a new line works fine)

Should a user then attempt to use crontab when banned, they would see a message along these lines:

You (username) are not allowed to use this program (crontab)
See crontab(1) for more information

[Mog]

je kunt het met een bash scriptje doen, maar via logrotate is wel de meeste nette manier inderdaad.

Overhuidelijk heb je ook wat in je config mis,
ik neem aan dat je met log "vol" bedoelt dat ie 2 gig is en je ext2 hebt ?

check even wat die in die error log wegschrijft want dat klinkt niet gezond 2 gig in 2 dagen.

[Pinocchi]

Je moet inderaad wel behoorlijk wat bezoekers hebben om in twee dagen 2 gig vol te krijgen aan accesslogs, maar altijd prettig natuurlijk om dergelijke aantallen bezoekers binnen te krijgen

[nielsje]

Origineel geplaatst door Mog
je kunt het met een bash scriptje doen, maar via logrotate is wel de meeste nette manier inderdaad.

Overhuidelijk heb je ook wat in je config mis,
ik neem aan dat je met log "vol" bedoelt dat ie 2 gig is en je ext2 hebt ?

check even wat die in die error log wegschrijft want dat klinkt niet gezond 2 gig in 2 dagen.

er past 5 gigabyte in de map waarin die staat.
en deze is dus ongeveer om de 2 dagen vol als ik niets zou deleten.

ik zal eens proberen een scripje te maken die het automatisch delete.
ik heb het nog nooit geprobeerd, maar als het mij lukt zal ik wel de code hier in het forum plaatsen

Origineel geplaatst door Pinocchi
Je moet inderaad wel behoorlijk wat bezoekers hebben om in twee dagen 2 gig vol te krijgen aan accesslogs, maar altijd prettig natuurlijk om dergelijke aantallen bezoekers binnen te krijgen

ja bezoekers lopen wel lekker en dataverkeer ook

[Herbert]

Je kunt ook webalizer gebruiken en na elke update je logs laten legen, dit kun je instellen in webalizer.
Ikzelf heb een extra partition aangemaakt ext3 van 10gig voor de logs die onafhankelijk staat van het root systeem.
Voordeel is als die 10gig vol is dan loopt het systeem niet vast.

[directservices]

Je kan het ook op deze manier doen :

rm -rf /map/access_log
touch /map/access_log

En dit in je cron zetten.

En wil je maar 1 cronjob aanmaken dan zet je de 2 regels in een .sh bestand en die chmod je naar 744. Dan kan je het .sh bestand uitvoeren.

[nielsje]

Origineel geplaatst door Flexvalue
Je kan het ook op deze manier doen :

rm -rf /map/access_log
touch /map/access_log

En dit in je cron zetten.

En wil je maar 1 cronjob aanmaken dan zet je de 2 regels in een .sh bestand en die chmod je naar 744. Dan kan je het .sh bestand uitvoeren.

Bedankt Flexvalue ben hem nu aan het 'testen' hopen dat ie goed loopt