MySQL karbantartása Drupal alatt

Egy korábbi hozzászólásban volt már róla szó, hogy miképp lehet a Drupal alatt a MySQL adatbázist menteni. Az ott tárgyalt accesslog és cache_* táblákat, hiába hagytuk ki a mentésből, valamilyen szinten karban kell tartani. Belenézve a táblák tartalmába nagyon úgy tűnik, hogy ezt a Drupal maga nem csinálja meg. Lehet, hogy van rá plugin/beállítás, de én csak az infrastruktúrát tartom karban, maga a Drupal másvalakihez tartozik. Ez gyakran így van web hosting esetén is, így nekünk kell karbantartani azt amit csak lehet, hogy ne harapózzanak el a dolgok a kelleténél jobban.

A lenti script ezt valósítja meg.

#!/bin/bash

# Beallitasok
DRUPAL_DB="drupal_db"
ACCESSLOG_SAVE_DAYS="31"
CACHE_SAVE_DAYS="7"

# A cron-nak
export MAILTO="nekem@ide.hu"

MYSQL="/usr/bin/mysql"

{
    # accesslog uritese
    DEADLINE=$(date -d "$ACCESSLOG_SAVE_DAYS days ago" '+%s')

    echo "Purging table accesslog..."
    echo -n "_T_Drop too old rows... "
    COUNT=$($MYSQL -B -s -e "DELETE FROM accesslog WHERE timestamp < $DEADLINE; SELECT ROW_COUNT();" "$DRUPAL_DB")
    echo "$COUNT rows."
    echo -n "_T_Optimizing... "
    RESULT=$($MYSQL -B -s -e "OPTIMIZE TABLE accesslog" "$DRUPAL_DB" | cut -f4-)
    echo "$RESULT."

    # Cache tablak uritese
    NOW=$(date '+%s')
    DEADLINE=$(date -d "$CACHE_SAVE_DAYS days ago" '+%s')

    $MYSQL -B -s -e "SHOW TABLES" "$DRUPAL_DB" | grep ^cache_ | \
    while read TABLE
    do
        echo "Purging table $TABLE..."

        # expire vizsgalata
        echo -n "_T_Drop expired rows... "
        COUNT=$($MYSQL -B -s -e "DELETE FROM $TABLE WHERE expire < $NOW AND NOT expire = 0; SELECT ROW_COUNT();" "$DRUPAL_DB")
        echo "$COUNT rows."

        # expired = 0 es created + CACHE_SAVE_DAYS vizsgalata
        echo -n "_T_Drop too old rows... "
        COUNT=$($MYSQL -B -s -e "DELETE FROM $TABLE WHERE expire = 0 AND created < $DEADLINE; SELECT ROW_COUNT();" "$DRUPAL_DB")
        echo "$COUNT rows."

        # optimalizalas
        echo -n "_T_Optimizing... "
        RESULT=$($MYSQL -B -s -e "OPTIMIZE TABLE $TABLE" "$DRUPAL_DB" | cut -f4-)
        echo "$RESULT."
    done

} 2>&1 | \
while read LINE
do
    echo "[$(date '+%Y-%m-%d %H:%M:%S')]_T_$LINE"
done | sed -e 's,_T_,\t,g'

Ezt használva volt, hogy az eredeti adatbázis 10%-ra esett a méret. Ez az OPTIMIZE TABLE parancsoknak köszönhető, ez végzi el a törölt rekordok fizikai eltávolítását (többek között). Hasonló a PostgreSQL VACUUM parancsához.

Gentoo hálózati konfiguráció és a link esete

Munkára egy notebook-ot használok. Mindenhova magammal cipelem, sok helyen kell az ottani helyi hálózatra kapcsolódnom. Erre találták ki a DHCP-t ami szépen működik is, azonban ha hálózati kábel nélkül kapcsolom be az eth0 interface felhúzásánál a gép szépen türelmesen várakozik, akár percekig is mire végül feladja.

Az alábbi kis kódrészletet beszúrva az /etc/conf.d/net állományba a probléma megoldódik (kell hozzá ethtool is):

preup()
{
        ETHTOOL="/usr/sbin/ethtool"
        IFCONFIG="/sbin/ifconfig"

        [ "$IFACE" == "eth0" ] || return 0

        [ -x "$ETHTOOL" ] && \
        {
                $IFCONFIG eth0 up
                sleep 2s

                # Ha meg igy sincs link...
                $ETHTOOL eth0 2>/dev/null | grep -q 'Link detected: no' && \
                {
                        ewarn "No link on eth0, aborting configuration"
                        return 1
                }

        }

        return 0
}

A preup függvényt minden a net.lo initscriptet használó interface felhúzása előtt meghívja az init rendszer.

Dovecot migráció

Szeretem a Dovecot-ot használni. Gyors, könnyen konfigurálható, sokat tud és aktívan fejlesztik. A minap egy ősrégi POP3 szerver alól kellett felhasználókat és adatokat migrálnom egy újonnan telepített Dovecot alá.

Az első lépés természetesen a Dovecot konfigurációja. Erről most nem írok, egyszerű, gyorsan megvan és nagyon jó leírással is rendelkezik a neten.

A felhasználókat a régi szerver eddig PAM-ból authentikálta, így a jelszavaik az /etc/shadow-ban voltak kódolva. A Dovecot esetében, mivel nem volt belső LDAP vagy AD, a passwdfile-os tárolást választottam (aminek nevével ellentétben semmi köze az /etc/passwd-hez és társaihoz). A rendszer régi volt, így a shadow-beli jelszavak még CRYPT-el voltak kódolva. A felhasználó migráció ennyiből állt mindössze.

cut -d: -f-2 /etc/shadow | sed -e "s,:,:{CRYPT}," -e "s,$,::::::," >> /etc/dovecot/auth/domain1.hu
chmod 0640 /var/jail/dovecot/etc/dovecot/auth/domain1.hu
chgrp dovecot /var/jail/dovecot/etc/dovecot/auth/domain1.hu

Ezek után ilyen sorok keletkeztek az /etc/dovecot/auth/domain1.hu állományban (természetesen a jelszó hasht véletlenszerűen módosítottam):

user:{CRYPT}$1$ezH6uhGsBq/fE$mei8Ohcheisakeef::::::

Ezek után be kell állítani az MTA-t, hogy mostantól a Dovecot-nak passzolja le a beérkező leveleket, leállítani a régi POP3 szervert, elindítani a Dovecot-ot. A felhasználók ilyenkor üres postafiókokat látnak, így ezt a lépést célszerű nem a munkaidő közepén végezni.

A levelek tárolására mbox állományok szolgáltak. A migrációt a dsync paranccsal a legkényelmesebb elvégezni.  Ez a Dovecot alapcsomag része és a migráción kívül számos más célra is használható (pl: backup, távoli szinkronizáció).

mkdir /var/tmp/mboxes
cd /var/tmp/mboxes
chmod 0777 /var/tmp/mboxes
mkdir /var/tmp/empty
chmod 0777 /var/tmp/empty
# nem biztos hogy minden felhasznalo letezik, akinek ott van meg a mailboxa
mkdir /var/tmp/mboxes/done
cp -pav $MBOXDIR/* .
chmod 0666 *
# elvegzem a konvertalasokat
for user in *
do
    dsync -v -R -u $user@domain.hu backup mbox:/var/tmp/empty:INBOX=/var/tmp/mboxes/$user && mv $user done/
done

Ez akár menetközben is képes a régi mbox-okból a leveleket bemigrálni a Dovecot alá. Többször is nyugodtan lehet futtatni, nem duplikálja a leveleket. A -R azért szükséges mivel alapértelmezésben a Dovecot postafiókjaiból (ami még üres) mentené a leveleket. A -R csak az irányt fordítja meg.

Kissé zavaró volt, hogy a régi szerveren csak egy mbox állomány volt, de mivel a Dovecot többet tud kezelni, így meg kell adni neki egy könyvtárat amiben keresi a többi foldert és külön megadható az INBOX-nak használt mbox állomány. Jelen esetben egy ősöreg POP3-only szerverről volt szó, ami nem támogatott csak egy INBOX-ot, így oda kellett hazudni egy üres könyvtárt.

Gyakorlati tapasztalat, hogy egy felhasználó törlésekor a postafiók tartalmát általában elfelejtik törölni, így lehet, hogy a fentiek elvégzése után még maradnak nem konvertált mbox-ok. Ezeket sajnos egyesével végig kell nézni, hogy pontosan mi is a helyzet.

Miután megtörtént a migráció, ne felejtsük ott a leveleket a /var/tmp alatt!

MySQL mentése Drupal alatt

A MySQL (érdemei elismerése mellett természetesen) jelenleg több komoly hiányossággal bír. Számomra a legirritálóbb a mentés nehézsége. Ha egy MyISAM engine-t használó táblát mentünk, akkor az a mentés idejére READ LOCK állapotba kerül, vagyis csak olvasni lehet belőle, az írások várakozni fognak (sajnos a hívó oldalon).

Egy közepes-alacsony látogatottságú, de már évek óta futó, Drupal oldal adatbázisának a mentése 20-30 percet vett igénybe (egy egyszerű mysqldump). Ezen időszak alatt a beérkező HTTP kéréseket az Apache elkezdte kiszolgálni, de az első olyan adatbázis műveletnél ami egy éppen mentés alatt álló táblába akart írni megállt a PHP feldolgozás és vele együtt az Apache folyamat is. Ahogy jöttek a kérések, egyre újabb és újabb Apache folyamatok indultak a kiszolgálásra, mivel szabad már egy sem volt. Ennek a spirálnak, ha nem szabadul fel időközben az adatbázis, két végkimenetele lehet, vagy eléri az Apache folyamatok száma a megengedett maximumot és nem fogad el új kéréseket, vagy pedig ez előtt elfogy a memória. Ebben az esetben ez utóbbi történt. Az oom-killer elkezdte kilövöldözni a folyamatokat ami miatt másnap reggelre a legváltozatosabb állapotokban lehetett a gépet találni.

A problémát többféleképp meg lehet oldani.

  1. Az adatbázis cseréje egy olyanra (pl: PostgreSQL) aminél ez nem okoz gondot. A Drupal támogatja a PostgreSQL-t, de egy éles oldal migrációja nem triviális feladat.
  2. Az adatbázis motor cseréje InnoDB-re. Ezt minden tábla alatt meg kell tenni. Az InnoDB lassabb, mint a MyISAM és a gyors netes keresések alapján többeknek ennek a mentésével is gondjuk adódott. Arról nem beszélve, hogy egy szoftver telepítésekor a jövőben nagy eséllyel ismét MyISAM-ot fog használni, így folyamatosan ellenőrizni kell. Ez kis nyereség, nagy adminisztrációs overhead mellett.
  3. Replikáció. A mentés a slave szerveren történik. Ez szép, de a jelenlegi helyzetben túl bonyolult és erőforrás zabáló megoldás. Nagyobb adatbázisok esetén azonban, szerintem, ez az egyetlen járható út, ha meg kell tartani a MySQL-t.
  4. Az adatbázis mentés alatt az Apache kiszolgálás leállítása. Ez természetesen minden nap egy 20-30 perces leállást jelent, ami nem elfogadható. A mentési idő a jövőben nőni fog, így az állásidő is egyre magasabb lesz.
  5. Racionalizálni a mentést, így csökkentve a mentési időt és az Apache folyamatok torlódását. Ez csak tüneti kezelés, de a fentiekkel ellentétben gyorsan és fájdalommentesen megvalósítható. További előny, hogy így a mentendő adatok mérete is csökken, azaz tárhelyet takarítunk meg.

Lássuk az 5. pont megvalósítását. A Drupal több cache és napló célú táblát használ (accesslog, cache_%), melyek mentése nem szükséges, visszaállítva az azokban tárolt adatok nélkül is működőképes. Természetesen a táblák definícióit el kell menteni, csak az adattartalmat lehet kihagyni.

Az alábbi scriptet a helyi viszonyokhoz igazítva (archívumok helye, adatbázis név stb.) pont ezt kapjuk. Ennek a segítségével a mentés ideje az eddigi 20-30 percről, 4-5 másodperc körüli értékre csökkent ami az oldal jelenlegi, vagyis akkori terhelése mellett bőven elegendő volt.

#!/bin/bash

# Beallitasok
DBNAME="sitename_drupal"
DEST_DIR="/mnt/backup/$(date +"%Y-%m-%d")"

# Binarisok
MYSQL="/usr/bin/mysql"
MYSQLDUMP="/usr/bin/mysqldump"

# Segedfuggvenyek
check_temporary_file()
{
        # Felbeszakadt mentes atmeneti allomanyanak a torles
        [ -f "$1-WIP" ] && \
        {
                echo -n "_T_Removing old temporary file [$1-WIP]..."
                rm -f "$1-WIP" && echo "done." || error 1
        }
}

compress_backup()
{
        echo -n "_T_Compressing backup $1..."
        if [ -f "$1.bz2" ]
        then
                echo "already done."
        else
                echo "background."
                bzip2 "$1" &
        fi
}

{
        # A cel konyvtar letrehozasa
        [ -d "$DEST_DIR" ] || \
        {
                echo -n "Creating destination directory [$DEST_DIR]..."
                mkdir -p "$DEST_DIR" && echo "done." || error 1
        }

        # Adatbazis mentes
        DEST_NAME="$DEST_DIR/MYSQL-$DBNAME-data.sql"
        check_temporary_file "$DEST_NAME"

        BAD_TABLES=$($MYSQL -B -s -e "SHOW TABLES" "$DBNAME" | grep -E '^cache_|^accesslog$')
        BAD_TABLES_OPTS=$(sed -e "s,^,--ignore-table=$DBNAME.," <<<"$BAD_TABLES")

        echo -n "_T_Dumping database $DBNAME..."
        if [ -f "$DEST_NAME.bz2" ]
        then
                echo "already done."
        else
                $MYSQLDUMP --quick $BAD_TABLES_OPTS --lock-tables --database "$DBNAME" | grep -v -- '^-- Dump completed on' > "$DEST_NAME-WIP"
                mv "$DEST_NAME-WIP" "$DEST_NAME"
                echo "done."
        fi

        compress_backup "$DEST_NAME"

        # Csak strukturak mentese
        if [ -n "$BAD_TABLES" ]
        then
                DEST_NAME="$DEST_DIR/MYSQL-$DBNAME-schema.sql"
                check_temporary_file "$DEST_NAME"

                echo -n "_T_Dumping database schemas from $DBNAME..."
                if [ -f "$DEST_NAME.bz2" ]
                then
                        echo "already done."
                else
                        $MYSQLDUMP --no-data $DBNAME $BAD_TABLES | grep -v -- '^-- Dump completed on' > "$DEST_NAME-WIP"
                        mv "$DEST_NAME-WIP" "$DEST_NAME"
                        echo "done."
                fi

                compress_backup "$DEST_NAME"
        fi
} 2>&1 | \
while read LINE
do
        echo "[$(date '+%Y-%m-%d %H:%M:%S')]_T_$LINE"
done | sed -e 's,_T_,\t,g'

A fenti script nem túl rugalmas, biztos lehet még rajta javítani, de a lényeg látszik belőle.

További kérdés, hogy az adatmentésből kihagyott táblákat időközönként takarítani is kellenne, de erről majd később.

 

IPv6 mentes Samba

Az újabb Samba verziók (3.5-tel biztosan) esetében a fordítás során már automatikusan detektálja az IPv6 támogatást, kikapcsolni configure opcióból már nem lehetséges, és a régebbi verziók miatt a Google tele van –disable-ipv6-os leírásokkal.

Ezzel a működéssel problémát jelent, ha a telepítés helyén csak IPv4 van. A Samba ebben az esetben is próbál AAAA rekordokat lekérdezni a DNS-ből, növelve a hálózati forgalmat és csökkentve a teljesítményt. Egy Squid mögé rakott AD-ból authentikáló Samba esetén ami már jelenleg is teljes mértékben ki van használva ez akár a végső lökés is lehet.

A megoldáshoz egy saját ebuild állományt kellett készítenem. Egy ipv4only USE-flage-et is raktam bele, hogy könnyen ki lehessen kapcsolni. Az eredeti Gentoo-s ebuild-hez képest csak ennyi a módosítás.

@@ -15,10 +15,10 @@
        http://dev.gentoo.org/~dagger/files/smb_traffic_analyzer_v2.diff.bz2"
 LICENSE="GPL-3"
 SLOT="0"
-KEYWORDS="~alpha amd64 ~arm hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc x86 ~x86-fbsd"
+KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 s390 sh sparc x86 ~x86-fbsd"
 IUSE="acl addns ads +aio avahi caps +client cluster cups debug doc examples fam
        ldap ldb +netapi pam quota +readline +server +smbclient smbsharemodes smbtav2
-       swat syslog winbind"
+       swat syslog winbind +ipv4only"

 DEPEND="dev-libs/popt
        !net-fs/samba-client
@@ -205,6 +205,15 @@
                --with-shared-modules=${SHAREDMODS} \
                --without-included-popt \
                --without-included-iniparser
+
+               if use ipv4only
+               then
+                       # A configure automatikusan billenti be a HAVE_IPV6 makrot, igy a
+                       # vegeredmenyben kell ezt modositani
+                       # ./source3/include/config.h:#define HAVE_IPV6 1
+                       sed -i -e 's,#define HAVE_IPV6 1,#undef HAVE_IPV6,' "${S}/include/config.h"
+               fi
+
 }

 src_compile() {

A +ipv4only miatt automatikusan be lesz kapcsolva a USE-flag, nem kell package.use-t módosítani.

AWStats és a Gentoo

Ha már csináltam blogot, akkor látni szeretném a látogatottsági statisztikáit is. A Google Analytics és társai által használt JavaScript kódok sosem voltak szimpatikusak, a saját használatú böngészőimben blokkolom is amiről tudok.

A szerver oldali napló feldolgozás, bár kevesebb információt ad, de azt biztosabb forrásból. Megjegyzem, számomra jelenleg a kliens böngészőjében futó kódok által nyújtott extra információk érdektelenek, nem vagyok kíváncsi a látogatók felbontása, a telepített Flash/Java pluginekre stb. Most csak az érdekel, hogy naponta mekkora adatmennyiséget kell kiszolgálnia a szervernek. Ez most és valószínűleg jó sokáig csak engem fog jelenteni, amint felnézek egy új postot írni vagy keresni a régebbiek között. :-)

Az AWStats egy kiváló eszköz a céljaim elérésére. Utoljára még a 6.x-es verzióval volt dolgom, most a 7.0-ással tettem próbát. Őszintén szólva nem láttam változást az új verzió által nyújtott szolgáltatásokban, de cserébe az eddigi kényelmes telepítés egy kicsit bonyolultabbá vált (bár ez a Gentoo package maintainer-ének a sara).

A telepítés a szokásos:

emerge -av awstats

A vhosts támogatás a 7-es verzióval megszűnt, két használható USE flag maradt, az ipv6 és a geoip. Ebből nekem csak az ipv6-ra volt szükségem (vagyis majd csak lesz, ha megleszek az IPv6-os elérés kiépítésével). A geoip lévén, hogy transzparens proxy mögött van az oldal, sok hasznot nem hajtott volna.

A telepítés után az /etc/awstats könyvtárban lehet a programot konfigurálni. Ehhez le kell másolni az ott található gyári awstats.model.conf állományt.

cd /etc/awstats
cp -pav awstats.model.conf awstats.arpad.syrius-software.hu.conf

Az általam végzett módosítások:

--- awstats.model.conf  2012-04-07 23:42:04.120968177 +0200
+++ awstats.arpad.syrius-software.hu.conf       2012-04-08 13:09:17.392151839 +0200
@@ -48,7 +48,7 @@
 # If there are several log files from load balancing servers :
 # Example: "/pathtotools/logresolvemerge.pl *.log |"
 #
-LogFile="/var/log/apache2/access_log"
+LogFile="/var/log/apache2/arpad.syrius-software.hu/access_log"

 # Enter the log file type you want to analyze.

A napló állomány helye, ez természetes.

@@ -150,7 +150,7 @@
 # Example: "ftp.domain.com"
 # Example: "domain.com"
 #
-SiteDomain="localhost"
+SiteDomain="arpad.syrius-software.hu"

 # Enter here all other possible domain names, addresses or virtual host
@@ -165,7 +165,7 @@
 # Note: You can also use @/mypath/myfile if list of aliases are in a file.
 # Example: "www.myserver.com localhost 127.0.0.1 REGEX[mydomain\.(net|org)$]"
 #
-HostAliases="localhost 127.0.0.1 REGEX[myserver\.com$]"
+HostAliases="arpad.syrius-software.hu" 

 # When AWStats updates its statistics, it stores results of its analysis in

A domain megadása.A HostAliases szerintem lehetne üres is, de így szoktam meg, hogy ezt is kitöltöm.

@@ -200,7 +200,7 @@
 # Example: "C:/awstats_data_dir"
 # Default: "."          (means same directory as awstats.pl)
 #
-DirData="."
+DirData="/var/lib/awstats"

 # Relative or absolute web URL of your awstats cgi-bin directory.

Adat könyvtár, az AWStats itt tárolja el a feldolgozások eredményeit, innen tudja, hogy hol tartott és mi az amit még meg kell csinálni. Minden hónaphoz külön szöveges adatbázist készít. Így ha újra akarjuk valamelyik hónapot generáltatni (pl: bővítettük az exclude listát), akkor elég letörölni innen a megfelelő állományt és ráfuttatni a régi naplókra ismét.

@@ -209,7 +209,7 @@
 # Example: "/awstats"
 # Default: "/cgi-bin"   (means awstats.pl is in "/yourwwwroot/cgi-bin")
 #
-DirCgi="/cgi-bin"
+DirCgi="/awstats"

 # Relative or absolute web URL of your awstats icon directory.

Az AWStats URL része. Ez nem kötelező lehet, csak akkor kell ha CGI-t is akarunk használni és nem csak statikus HTML-eket generálni. Én most akartam CGI-t használni.

@@ -276,7 +276,7 @@
 # Possible values: 0 or 1
 # Default: 0
 #
-EnableLockForUpdate=0
+EnableLockForUpdate=1

 # AWStats can do reverse DNS lookups through a static DNS cache file that was

Mivel le van tiltva a CGI felületéről a naplók újrafeldolgozása, így ennek értelme nem sok, de ártani nem árt.

@@ -494,7 +494,7 @@
 # Example: "/badpage.php /page.php?param=x REGEX[^\/excludedirectory]"
 # Default: ""
 #
-SkipFiles=""
+SkipFiles="REGEX[^\/awstats]"

 # Use SkipReferrersBlackList if you want to exclude records coming from a SPAM

Nem akartam a statisztikában látni az AWStats nézegetéséből kapott oldalletöltéseket.

@@ -843,7 +843,7 @@
                                     # 2 reduces AWStats speed by 1%
 LevelForFileTypesDetection=2        # 0 disables File types detection.
                                     # 2 reduces AWStats speed by 1%
-LevelForWormsDetection=0            # 0 disables Worms detection.
+LevelForWormsDetection=2            # 0 disables Worms detection.
                                     # 2 reduces AWStats speed by 15%

Erőforrás van, hátha látok itt egyszer valamit. :-)

@@ -966,12 +966,12 @@
 # Show domains/country chart
 # Context: Web, Streaming, Mail, Ftp
 # Default: PHB, Possible column codes: PHB
-ShowDomainsStats=PHB
+ShowDomainsStats=0

 # Show hosts chart
 # Context: Web, Streaming, Mail, Ftp
 # Default: PHBL, Possible column codes: PHBL
-ShowHostsStats=PHBL
+ShowHostsStats=0

 # Show authenticated users chart
 # Context: Web, Streaming, Ftp

Itt csak a transzparens proxy belső lábát láthatom, nem túl izgalmas, így nem is kell.

@@ -986,7 +986,7 @@
 # Show worms chart
 # Context: Web, Streaming
 # Default: 0 (If set to other than 0, see also LevelForWormsDetection), Possible column codes: HBL
-ShowWormsStats=0
+ShowWormsStats=1

 # Show email senders chart (For use when analyzing mail log files)
 # Context: Mail

Ha már próbálunk worm-öket keresni, akkor ne tartsuk magunkban az eredményt.

@@ -1280,7 +1280,7 @@
 # DESCRIPTION: Add tooltips pop-up help boxes to HTML report pages.  
 # NOTE: This will increased HTML report pages size, thus server load and bandwidth.
 #
-#LoadPlugin="tooltips"
+LoadPlugin="tooltips"

 # PLUGIN: DecodeUTFKeys
 # REQUIRED MODULES: Encode and URI::Escape

Szeretem a felugró tooltip-eket. Legalábbis most ezt gondolom.

Ezzel megvolnánk, most már csak működésre kell bírni és megjeleníteni az eredményt. Javasolt a működéssel kezdeni.

A /var/lib/awstats alá bekerülő állományokat az Apache felhasználójának (itt most apache) is olvasnia kell tudnia (írni nem).

chgrp apache /var/lib/awstats
chmod 2750 /var/lib/awstats

A kettes nem elírás az elején, hanem a SetGID bit.

Rá kell bírni valahogy hogy adott időközönként le is fusson. Ehhez én most a logrotate prerotate scriptjét használtam. Ez csak ilyen kis forgalmú weboldalak esetén járható út, mivel amíg fut a feldolgozás, addig áll a logrotate. Ha lesz időm, akkor megpróbálom a postrotate-be áttolni.

# Apache2 logrotate snipet for Gentoo Linux
# Contributes by Chuck Short
#
/var/log/apache2/*log /var/log/apache2/*/*log {
  daily
  rotate 14
  missingok
  notifempty
  sharedscripts
  prerotate
        /usr/bin/awstats_updateall.pl now &> /tmp/awstats.log || true
  endscript
  postrotate
        /etc/init.d/apache2 reload > /dev/null 2>&1 || true
  endscript
}

Az /usr/bin/awstats_updateall.pl egy wrapper Perl script ami végignézi az /etc/awstats könyvtárat és minden ott talált konfigurációs állománnyal meghívja az awstats.pl scriptet ami tényleges napló feldolgozást végzi.

Ezzel kész a működés, már csak a megjelenítés van hátra. Ehhez keressük meg az Apache konfigurációban a nekünk szimpatikus virual host-ot és szúrjuk be az alábbiakat a VirtualHost szekcióba:

        # AWStats
        Alias /awstats/classes  "/usr/share/awstats/wwwroot/classes/"
        Alias /awstats/css      "/usr/share/awstats/wwwroot/css/"
        Alias /awstats/icon     "/usr/share/awstats/wwwroot/icon/"
        ScriptAlias /awstats/   "/usr/share/awstats/wwwroot/cgi-bin/"
        ScriptAlias /awstats    "/usr/share/awstats/wwwroot/cgi-bin/awstats.pl"
        ScriptAlias /awstats.pl "/usr/share/awstats/wwwroot/cgi-bin/awstats.pl"

        <Directory /usr/share/awstats>
                Order           allow,deny
                Allow from      all
        </Directory>

        <Directory /usr/share/awstats/wwwroot/cgi-bin>
                Options         ExecCGI
        </Directory>

Fontos, hogy ezt csak akkor csináljuk így ha csak egy oldalról van szó vagy mindegyik oldalhoz csak mi férünk hozzá! Az AWStats CGI scriptjének megadható a config GET paraméterben hogy melyik konfigurációs állományból dolgozzon, így melyik weboldal statisztikáit mutassa meg. Pl:

http://egyikoldal.hu/awstats?config=masikdoldal.hu

Ebben az esetben az AWStats az /etc/awstats/awstats.masikoldal.hu.conf állományt használja.

Első post

Ennek a blognak egy célja van, összegyűjteni azokat a tudásmorzsákat, ismereteket amikre az informatikai munkám során szert teszek. Eddigi tapasztalataim alapján az amit az ember gyakran, mindennap használ, az hamar és mélyen rögzül, de a ritka és emiatt általában egzotikus megoldást, trükköket igénylő esetek részletei lassan a feledés ködébe merülnek.

Néha előkeresem egy-egy régebbi, általam konfigurált szerver elmentett állományait (ha egyáltalán megvannak még) és rácsodálkozom, hogy akkoriban mi mindent meg nem tudtam oldani. Nem egyszer előfordul, hogy emellé társul egy enyhe fejfalbaverési kényszer is amikor ráébredek, hogy az előttem látható megoldás mennyi munkától mentett volna meg a közelmúltban.

Ez a blog tehát egy digitális jegyzettömb, akkor írok bele amikor aktuális, nem tervezek semmilyen rendszert. A kinézettel sem tervezek foglalkozni, amíg az információ elérhető, addig a külalak nekem nem sokat számít és az sem mellékes, hogy nincs sem tudásom, egyesek szerint sem érzékem ahhoz, hogy esztétikussá tegyem.

Ha rajtam kívül más is az Internet eme sötét bugyrába tévedne, akkor csak hajrá. Nyugodtan használd fel az itt található információkat, és javíts ki ha tévednék valamiben.