Uitvoeren snelheidstest (4)

Naar aanleiding van het vorige bericht heb ik maar even een hele simpele test uitgevoerd vanaf mijn servertje. Ik heb namelijk even een iso binnengehaald vanaf de debian ftp server, de nederlandse mirror uiteraard:

ftp> get debian-40r3-amd64-kde-CD-1.iso
local: debian-40r3-amd64-kde-CD-1.iso remote: debian-40r3-amd64-kde-CD-1.iso
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for debian-40r3-amd64-kde-CD-1.iso (678758400 bytes).
226 File send OK.
678758400 bytes received in 168.75 secs (3927.9 kB/s)

Ik heb trouwens het eerste stukje weggelaten, het was nog even zoeken waar de iso’s geplaatst waren. Maar het geeft in elk geval aan dat ik wat betreft de downloads de snelheid van 35 mbit/s redelijk halen kan. Dit komt namelijk neer op 35 / 8 * 1024 = 4480 KiB/s, er gaat echter nog een stukje overhead af van het TCP/IP protocol. Dit is tussen de 10% en 20%, dus tussen de 3584 KiB/s en 4032 KiB/s, de gehaalde waarde ligt rond de 12% dus dat is netjes.

Ook aan de kant van Armorica gaat het goed trouwens:

ftp> get debian-40r3-amd64-netinst.iso
local: debian-40r3-amd64-netinst.iso remote: debian-40r3-amd64-netinst.iso
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for debian-40r3-amd64-netinst.iso (151877632 bytes).
226 File send OK.
151877632 bytes received in 32.19 secs (4607.3 kB/s)

Ik heb hier wel een iets kleiner bestand binnengehaald, de nauwkeurigheid zal dus iets lager zijn maar ik mag er wel vanuit gaan dat er snelheden haalbaar zijn van boven de 4000 KiB/s.

Ik moet dus echt verder zoeken naar de oorzaak van de slechte resultaten tijdens de vorige tests.

Uitvoeren snelheidstest (3)

Het duurt nogal voordat er resultaten komen van de snelheidstesten waar ik mee bezig ben. Ik kom namelijk nog niet aan de waarde die ik hoor te hebben. Nu kan het natuurlijk best zijn dat mijn werkelijke snelheid bij lange na niet in de buurt komt van de geadverteerde snelheid. Maar ik denk eerder dat er iets misgaat bij het testen. Ik kreeg namelijk gisteravond met het installeren van OpenArena een downloadsnelheid die schommelde tussen de 3500 en 4000 KiB/s, vlak daarna heb ik nog een test uitgevoerd en die zie je onderin de volgende lijst:

Datum	Tijd	Download	Upload
18-06	16:23	2,62		1,56
18-06	21:52	0,82		0,98
18-06	22:58	1,55		1,29
18-06	23:47	2,04		1,49
19-06	0:19	2,45		1,40
19-06	6:18	2,85		1,59
19-06	9:18	2,49		1,60
19-06	12:18	2,71		1,63
19-06	15:18	2,58		1,65
19-06	18:19	2,07		1,45
20-06	0:20	1,95		1,43
20-06	6:18	2,82		1,64
21-06	0:18	2,48		1,60
21-06	6:18	2,85		1,61
25-06	22:03	1,61		1,26

De gemeten waarde’s hier zijn in MiB/s, de downloadsnelheid is hier nog niet de helft van de waarde die ik even daarvoor gehaalt heb op mijn werkstation.

Voor de volledigheid hier nog even het script wat ik gebruik om de snelheidstesten uit te voeren:

#!/bin/sh

cd ~/test
filename="400MB.test"
hostname="tecumseh.homeip.net"
username="supergeheimtestgebruiker"
password="supergeheimwachtwoord"
echo -e "***tecumseh.homeip.net Download snelheid***\n" >> speedtest.log
ftp -inv $hostname >> speedtest.log << EOF
quote USER $username
quote PASS $password
binary
put $filename
bye
EOF

echo -e "\n"
echo -e "***tecumseh.homeip.net Upload snelheid***\n" >> speedtest.log
ftp -inv $hostname >> speedtest.log << EOF
quote USER $username
quote PASS $password
binary
get $filename
bye
EOF

#REMOVE GARBAGE (REMOVE EVERY LINE EXCEPT FOR ONES CONTAINING '*' AND 'MB') FROM LOG FILE AND EMAIL IT
#sed -n -e '/*/p' -e '/MB/p' speedtest.log >> email.log
mail -s "Speed Test Results" ********@provider.nl < speedtest.log
rm speedtest.log
#rm email.log

Uiteraard zijn de logingegevens en het mailadres hier even veranderd. Zoals je ziet heb ik de sed regel weggelaten. Dit leverde nogal onverwachte resultaten op. Namelijk een bijna leeg mailtje waarin enkel de regels kwamen waarin het testbestand genoemd wordt (400MB.test)

Ik moet nu dus nog even op zoek naar een manier om uit te vogelen waar de bottleneck zit.

Lighttpd logrotate

Ik heb recent wat aanpassingen gedaan aan de logrotate. Dit om het maken van statistieken voor de website wat makkelijker te maken.

Helaas is er iets foutgegaan, afgelopen nacht heeft om 00:02 de logrotate zijn werk gedaan. Ik had echter een regel vergeten terug te voeren die lighttpd zou moeten stoppen en de rechten van de access.log werden niet voor user/group www-data aangemaakt maar voor root. Hierdoor mis ik de statistieken van 00:02 t/m 10:47

Uitvoeren snelheidstest (2)

Mijn idee was om de testen uit te voeren met behulp van een ftp-server. Deze moet dus geïnstalleerd worden op de Strato testserver:

ve120:~# aptitude install pure-ftpd
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
The following NEW packages will be automatically installed:
  libdb4.4 perl perl-doc perl-modules pure-ftpd-common
The following NEW packages will be installed:
  libdb4.4 perl perl-doc perl-modules pure-ftpd pure-ftpd-common
0 packages upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 14.7MB of archives. After unpacking 45.1MB will be used.
Do you want to continue? [Y/n/?] y

Voor het lokaal testen van de ftp server installeer ik het pakket ftp. Deze kan ik door het gebruik van aptitude na de lokale test volledig verwijderen. Dit in tegenstelling tot apt-get wat de dependency’s die meegeïnstalleerd worden niet meeneemt met het verwijderen:

ve120:~# aptitude install ftp
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
The following NEW packages will be automatically installed:
  libreadline5 readline-common
The following NEW packages will be installed:
  ftp libreadline5 readline-common
0 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 246kB of archives. After unpacking 688kB will be used.
Do you want to continue? [Y/n/?] y

Nu ik bedenk dat ik met het pakket ftp ook lokaal testen uit kan voeren, dan zou ik de testen toch eigenlijk net zo goed vanuit de testserver naar mijn eigen server kunnen doen. In een moment van verstandsverbijstering heb ik dan ook het volgende gedaan:

ve120:/etc# aptitude remove --purge pure-ftpd
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
The following packages are unused and will be REMOVED:
  libdb4.4{p} perl{p} perl-doc{p} perl-modules{p} pure-ftpd-common{p}
The following packages will be REMOVED:
  pure-ftpd
0 packages upgraded, 0 newly installed, 6 to remove and 0 not upgraded.
Need to get 0B of archives. After unpacking 45.1MB will be freed.
Do you want to continue? [Y/n/?] y
ftp> open tecumseh.homeip.net
Connected to tecumseh.homeip.net.
220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
220-You are user number 2 of 50 allowed.
220-Local time is now 23:39. Server port: 21.
220-This is a private system - No anonymous login
220 You will be disconnected after 15 minutes of inactivity.
Name (tecumseh.homeip.net:root): USER *
331 User USER uploadtest OK. Password required
Password:
530 Login authentication failed
Login failed.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> exit
221-Goodbye. You uploaded 0 and downloaded 0 kbytes.
221 Logout.

Op de een of andere manier kom ik dus niet eens bij mijn server. Na het uitloggen zie ik wel de volgende melding:

ftp: bind: Address already in use

Op het eerder genoemde forum van Henk noem ik ook dit probleem. Hij heeft gelukkig het probleem snel gevonden en de oplossing aangeleverd, dit is op de openvz machine doorgevoerd waardoor ik er niets meer mee hoefde te doen. Ik kwam trouwens zelf al op het idee om in plaats van actieve ftp passieve ftp te gebruiken, dit door de ftp server te starten met het commando pftp, hiermee word dus direct een passieve sessie geopend. Hierdoor zou Henk dus de module ip_nat_ftp kunnen verwijderen. Iets wat ik ook best wil testen maar ik wil eerst nog een en ander doen met de ftp-server.

In de tijd die zat tussen het melden van het probleem en de aangedragen oplossing heb ik een paar testen uitgevoerd met SCP, als eerste het versturen van tecumseh.homeip.net naar armorica.tk:

Arkon:~# scp test/400MB.test Armorica:400MB.test
root@ve120.armorica.tk's password:
400MB.test                                    100%  400MB   2.0MB/s   03:21
Arkon:~# scp -c blowfish test/400MB.test Armorica:400MB.test
root@ve120.armorica.tk's password:
400MB.test                                    100%  400MB   2.2MB/s   03:04
Arkon:~# scp -c blowfish -i ~/.ssh/Armorica test/400MB.test Armorica:400MB.test
400MB.test                                    100%  400MB   2.2MB/s   03:04

De blowfish toevoeging heb ik gedaan omdat volgens verschillende pagina’s op het internet hiermee een hogere snelheid behaalt wordt omdat de encryptie minder sterk is. Zoals je kunt zien zit hier ook daadwerkelijk een verschil van 0.2 MiB/s.

Het terughalen van dit bestand gaat ook prima:

Arkon:~# scp -c blowfish -i ~/.ssh/Armorica Armorica:400MB.test .
400MB.test                                    100%  400MB   2.2MB/s   03:06

Helaas zijn de snelheden wat magertjes, ik verwacht namelijk ongeveer het dubbele. Mijn vermoeden is dat dit aan de encryptie ligt die scp er overheen zet.

Het uitzoeken van de syntax van scp heeft me nog wel wat hoofdbrekers gekost. Deze pagina heeft me in elk geval een heel eind op weg geholpen.

Uitvoeren snelheidstest

Zoals in mijn vorige snelheidsbericht te lezen valt heb ik een aanbod gekregen om mijn snelheid te bepalen met een door Henk van de Kamer beschikbaar gestelde server.

Op 17 juni kreeg ik van Henk dan ook een leuk mailtje, de logingegevens voor de testserver zat er namelijk in. Het gaat hier om een virtuele machine die op een Strato rootserver draait. Meer informatie over deze server vindt je hier.

Als eerste zal ik de login gemakkelijk maken door een aantal zaken te regelen. Ik maak volgens deze beschrijving een configuratiebestand aan voor ssh waardoor ik geen loginnaam en ip-adres meer hoef te onthouden. Hierin voer ik de volgende gegevens in:

host=Armorica
hostname=ve120.armorica.tk
port=12022
User=root

Hiermee kan ik in elk geval een eerste login doen:

tecumseh@Athlan:~$ ssh Armorica
The authenticity of host '[ve120.armorica.tk]:12022 ([85.214.61.55]:12022)' can't be established.
RSA key fingerprint is 80:76:12:8b:1c:95:ee:b8:3b:71:b0:18:be:d7:7b:a5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[ve120.armorica.tk]:12022,[85.214.61.55]:12022' (RSA) to the list of known hosts.
tecumseh@ve120.armorica.tk's password:
Linux ve120.armorica.tk 2.6.18-openvz-amd64-k8 #1 Fri Mar 14 12:52:28 CET 2008 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
ve120:~#

Vervolgens kan ik een publieke en persoonlijke sleutel aanmaken zoals ik al eerder heb gedaan. Nu is het best leuk dat ik de commando’s handmatig invoer maar dan moet je natuurlijk geen typefout maken. Zoals je hier kan lezen kwam ik een dag later achter de oorzaak van het probleem.

Nog even een laatste toevoeging doen aan ~/.ssh/config en dat is de parameter IdentityFile, die laat ik wijzen naar mijn prive sleutel waardoor ik helemaal geen invoer hoef te doen om op de testserver in te loggen.

Awstats logging

Nu draait dit blog al wel een paar maanden maar nog steeds heb ik de statistieken niet voor elkaar. Het wordt hoog tijd om daar verandering in aan te brengen. De keuze is voor mij gevallen op AWStats. Deels omdat ik hier in mijn Freesco verleden al mee gewerkt heb. Deze keer ga ik het echter niet als actieve CGI pagina installeren, de statistieken moeten dagelijks in de nachtelijke uren geupdate gaan worden waarna de statische pagina’s beschikbaar komen op de webserver.

Als eerste Awstats en de geoip plugin installeren vanuit de Debian archieven:

Arkon:~# aptitude install awstats libgeo-ipfree-perl

De configuratie heb ik in de eerste instantie vrij grof gedaan. Simpelweg de basisconfiguratie geconfigureerd naar een apart bestand voor dit domein, dat werdt dus awstats.tecumseh.homeip.net.conf. Hierin de juiste variabelen aanpassen en kijken of ik een statische pagina aanmaken kan.

Ik kom er achter dat de bestanden niet allemaal op dezelfde plek staat. Eerst dus maar zorgen dat het script om de statische pagina’s te maken op dezelfde plaats aangeroepen kan worden als het hoofdscript van awstats:

Arkon:/usr/lib/cgi-bin# ln -s /usr/share/doc/awstats/examples/awstats_buildstaticpages.pl awstats_buildstaticpages.pl

Hierna kan ik een update uitvoeren en een set statische pagina’s aanmaken, dit moet straks vanuit een bash script gedaan worden:

Arkon:~$ /usr/lib/cgi-bin/awstats.pl -config=tecumseh.homeip.net -update
Arkon:~$ /usr/lib/cgi-bin/awstats_buildstaticpages.pl -awstatsprog=/usr/lib/cgi-bin/awstats.pl -config=tecumseh.homeip.net -year=2008 -month=06 -dir=~/awstats/200806

Dit werkt in elk geval, ik krijg statistieken maar het is allemaal wel heel kaal. De icoontjes worden niet gevonden. Deze dus maar aanmaken via een symlink:

Arkon:~/tecumseh.homeip.net/awstats$ ln -s /usr/share/awstats/icon/ icon

Zorg er trouwens wel voor dat de locatie van de icoontjes in de configuratiebestanden aangepast wordt naar deze locatie.

Nu nog even een opschoning doen in het configuratiebestand. Ik wil hier niets meer in hebben staat wat ook in een algemeen configuratiebestand kan staan. We kopieren awstats.conf dus naar awstats.conf.local, hiermee zorgen we ervoor dat er bij een update van het pakket de originele configuratie niet verloren gaat. In dit bestand commenten we een aantal regels die we per domein apart in willen stellen, die regels laten we dus terugkomen in aparte configuratiebestanden:

LogFile="/var/log/lighttpd/access.log"
SiteDomain="tecumseh.homeip.net"
DirData="/var/lib/awstats"
DefaultFile="index.php"
SkipFiles="REGEX[^\/phpmyadmin] REGEX[^\/postfixadmin]"
NotPageList="css js class gif jpg jpeg png bmp ico swf"
MiscTrackerUrl="/js/awstats_misc_tracker.js"
DetailedReportsOnNewWindows=0
LoadPlugin="geoipfree"
Include "/etc/awstats/awstats.conf.local"

Als we nu de statistieken opnieuw aanmaken dan krijgen we ineens de volgende regel bovenaan de pagina te staan:

Warning: Perl versions before 5.6 cannot handle nested includes

Na lang zoeken kwam ik erachter dat ik een fout gemaakt heb in de configuratiebestanden. Het probleem bleek te zitten in awstats.conf.local, deze verwees namelijk naar zichzelf in de laatste regel aangezien dit een kopie is van awstats.conf, door deze regel te commenten verdwijnt de foutmelding.

Nu kunnen we de domeinconfiguratiebestanden copieren en per domein aanpassen.

Als ik vervolgens bij een domein wat ik tot nu toe enkel nog voor testdoeleinden gebruikt heb de statistieken bekijk dan zijn die verdacht gelijk aan mijn hoofdaccount. Ik kan me niet voorstellen dat dit de bedoeling is.

Ik heb namelijk LogFormat op 1 staan, wat de volgende zoekstring opleverd:

# LogFormat = "%host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"

Het 2e veld %other is echter de naam van de virtualhost, als ik het format verander naar:

LogFormat = "%host %virtualname %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"

Dan krijg ik de statistieken wel bij de site waar ze thuishoren.

Er staat nog wel het een en ander op het programma, dit is nog verre van volmaakt.

  • Logrotate aanpassen waardoor ik logbestanden per maand heb.
  • Script maken voor automatische verwerking
  • Statistieken in de site verwerken, deze site publiek en de overige achter een wachtwoord
  • Extra statistieken actief maken door het gebruik te maken van awstats_misc_tracker.js

Nu heb ik voor bovenstaande items wel wat leesvoer gevonden, dit is echter op apache geschreven en ik heb een lighttpd server.

Wordt vervolgt dus.

Snelheidstest glasvezel

Ik heb het in diverse posts al gehad over de snelheid van mijn glasvezelverbinding. Nu is er nog geen test uitgevoerd die voldoende data gebruikt heeft om betrouwbare resultaten te geven. In het laatste glasvezel topic bied Henk aan om een Strato testserver te mogen gebruiken om mijn snelheid op wetenschappelijke wijze te bepalen.

Voor het wetenschappelijke verhaal heb ik een stukje in de mail gekregen van Henk:

> Ik wil dus nog uitzoeken of je met behulp van een script
> snelheidswaarde’s kunt meten op meerdere momenten tijdens een grote
> upload. Ik ga daarbij aannemen dat de 1e 20% van een upload niet
> representatief is. Wellicht heb jij daar nog ideeën over.

Dit klinkt heel goed. Alleen gaat die handshake en window scaling vrij snel, ofwel de eerste 20% gaat wat ver. Zelf neem ik altijd een bestand dat minimaal een minuut kost. Je moet namelijk aannemen dat de gemeten tijdsduur ± 1 seconde is. Ofwel als jij 120 MiB weet te uploaden in een minuut kom je uit op:

120 / 59 = 2,03
120 / 61 = 1,97

Je ziet dat allebei afgerond kan worden op 2,0 MiB/s ofwel één cijfer achter de komma en dat is goed genoeg voor dit soort testen.

Als je snelheid een heel stuk meer is, wordt één minuut mogelijk al te weinig:

240 / 59 = 4,07
240 / 61 = 3,93

Kortom je moet dus zoveel data gebruiken dat met de gevonden tijd een nauwkeurig uitspraak is te doen…

Aangezien mijn theoretische snelheid op 35 mbit zit volgens Concepts ICT heb ik een snelheid van:

35 / 8 = 4,375 MiB/s

Een test die een duur heeft tussen de 1,5 en 2 minuten heeft dus een bestand nodig van minimaal 393,75 MiB (90 * 4,375) en maximaal 525 MiB (120 * 4,375). Aangezien het TCP/IP protocol een verlies van zo’n 10% heeft neem ik de laagste waarde en rond die iets naar boven af en zo kom ik uit op een testbestand van 400 MiB. Deze maak ik dan ook aan:

Arkon:~/test# dd if=/dev/zero of=400MB.test bs=1M count=400
400+0 records in
400+0 records out
419430400 bytes (419 MB) copied, 28.3245 seconds, 14.8 MB/s

Om zeker te zijn dat mijn machine’s de test wel volledig uit kunnen voeren zal ik de test eerst uitvoeren tussen mijn server Arkon en mijn werkstation. Als ik daarmee niet boven de 4,5 MiB/s uitkom dan heeft het verder testen geeneens nut.

Voor het testen maak ik gebruik van een bash script. Na lang zoeken heb ik er een gevonden, zo’n ster ben ik nog niet in het zelf bedenken van scripts. Wel heb ik hierin ondertussen de sed regel gecomment en uiteraard de variabelen aangepast. Er werdt me wel heel veel weggelaten, zoals bijvoorbeeld de snelheid. En daar gaat het uiteindelijk om.

***FTP SERVER UPLOAD SPEED***

220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Using binary mode to transfer files.
331 User tecumseh OK. Password required
200 TYPE is now 8-bit binary
local: 400MB.test remote: 400MB.test
226-File successfully transferred
226 39.745 seconds (measured here), 10.06 Mbytes per second
419430400 bytes sent in 39.73 secs (10308.5 kB/s)
221 Logout.

***FTP SERVER DOWNLOAD SPEED***

220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Using binary mode to transfer files.
331 User tecumseh OK. Password required
200 TYPE is now 8-bit binary
local: 400MB.test remote: 400MB.test
226-File successfully transferred
226 48.714 seconds (measured here), 8.21 Mbytes per second
419430400 bytes received in 48.21 secs (8495.7 kB/s)
221 Logout.

Ruim 10 MiB/s voor de upload en ruim 8 MiB/s voor de download. Dit ligt ruim 2x boven de hierboven genoemde theoretische snelheid van mijn verbinding. De systemen hier kunnen het dus aan.

MySQL Backup

Ik loop al een tijdje achter met het automatisch correct afhandelen van de backup. Ik heb wel een backup script draaiende maar die functioneerd nog niet naar wens. Eigenlijk wil ik namelijk een dagelijkse, wekelijkse en maandelijkse backup hebben van elke database apart. Het liefst ook nog met de mogelijkheid om de backup extern op te slaan.

Aangezien ik nog maar net begin met het schrijven van bash-scripts ben ik dus een zoektocht begonnen. En daarmee is meteen de kans een stuk groter dat je een script vindt dat heel dicht bij je wensen in de buurt komt. En dat is Automatic MySQL Backup geworden.

Als eerste nog even een aparte database user aanmaken die enkel select rechten heeft:

CREATE USER 'mysqlbackupuser'@'localhost' IDENTIFIED BY '************';

GRANT SELECT ON * . *
TO 'mysqlbackupuser'@'localhost'
IDENTIFIED BY '************'

De rest van de instellingen spreken voor zich, ik heb er even over zitten te denken om me elke keer de backupfiles toe te laten zenden per mail. De meest logische mailbox is dan gmail in verband met het extern opslaan. Bij nader inzien doe ik dat maar niet, je weet nooit wat google ermee zou willen en kunnen doen.

Voor het wegzetten van de backup moet ik dus nog iets anders gaan doen, hiervoor kan ik een apart script gaan gebruiken die ik in dit script aanroep:

# Command to run before backups (uncomment to use)
#PREBACKUP="/etc/mysql-backup-pre"

# Command run after backups (uncomment to use)
#POSTBACKUP="/etc/mysql-backup-post"

Ik zit er dus aan te denken om het backuppen van de gegevens op schijf (/var/www, /etc, /home) in het pre script uit te voeren en om het wegzetten van de data naar een externe locatie in het post script te verwerken.

Na een testrun zie ik dat ik de database-user nog iets meer rechten moet geven. Lock-tables is ook wel handig zodat je geen conflicterende backup krijgt:

REVOKE ALL PRIVILEGES ON * . * FROM 'mysqlbackupuser'@'localhost';

REVOKE GRANT OPTION ON * . * FROM 'mysqlbackupuser'@'localhost';

GRANT SELECT ,
LOCK TABLES ON * . *
TO 'mysqlbackupuser'@'localhost';

Hierna krijg ik na een tweede test netjes een berichtje in mijn mailbox wat me de resultaten verteld:

======================================================================
AutoMySQLBackup VER 2.5
http://sourceforge.net/projects/automysqlbackup/

Backup of Database Server - Arkon
======================================================================
Backup Start Time Fri Jun 6 13:59:17 CEST 2008
======================================================================
Daily Backup of Database ( information_schema )
Rotating last weeks Backup...

Backup Information for
/backup/mysql/daily/information_schema/information_schema_2008-06-06_13h59m.Friday.sql
         compressed        uncompressed  ratio uncompressed_name
                479                1241  66.7%
/backup/mysql/daily/information_schema/information_schema_2008-06-06_13h59m.Friday.sql
----------------------------------------------------------------------
Daily Backup of Database ( database1 )
Rotating last weeks Backup...

Backup Information for
/backup/mysql/daily/database1/database1_2008-06-06_13h59m.Friday.sql
         compressed        uncompressed  ratio uncompressed_name
             130792              669262  80.5%
/backup/mysql/daily/database1/database1_2008-06-06_13h59m.Friday.sql
----------------------------------------------------------------------
Daily Backup of Database ( database2 )
Rotating last weeks Backup...

Backup Information for
/backup/mysql/daily/database2/database2_2008-06-06_13h59m.Friday.sql
         compressed        uncompressed  ratio uncompressed_name
              43350              167174  74.1%
/backup/mysql/daily/database2/database2_2008-06-06_13h59m.Friday.sql
----------------------------------------------------------------------
Daily Backup of Database ( database3 )
Rotating last weeks Backup...

Backup Information for /backup/mysql/daily/database3/database3_2008-06-06_13h59m.Friday.sql
         compressed        uncompressed  ratio uncompressed_name
               1685                8489  80.8%
/backup/mysql/daily/database3/database3_2008-06-06_13h59m.Friday.sql
----------------------------------------------------------------------
Daily Backup of Database ( mysql )
Rotating last weeks Backup...

Backup Information for /backup/mysql/daily/mysql/mysql_2008-06-06_13h59m.Friday.sql
         compressed        uncompressed  ratio uncompressed_name
              95645              315867  69.7%
/backup/mysql/daily/mysql/mysql_2008-06-06_13h59m.Friday.sql
----------------------------------------------------------------------
Daily Backup of Database ( database4 )
Rotating last weeks Backup...

Backup Information for
/backup/mysql/daily/database4/database4_2008-06-06_13h59m.Friday.sql
         compressed        uncompressed  ratio uncompressed_name
               1014                2595  63.1%
/backup/mysql/daily/database4/database4_2008-06-06_13h59m.Friday.sql
----------------------------------------------------------------------
Daily Backup of Database ( database5 )
Rotating last weeks Backup...

Backup Information for
/backup/mysql/daily/database5/database5_2008-06-06_13h59m.Friday.sql
         compressed        uncompressed  ratio uncompressed_name
             141987              652025  78.2%
/backup/mysql/daily/database5/database5_2008-06-06_13h59m.Friday.sql
----------------------------------------------------------------------
Backup End Fri Jun 6 13:59:22 CEST 2008
======================================================================
Total disk space used for backup storage..
Size - Location
944K /backup/mysql

Ik heb in dit overzicht overigens wat bestands- en databasenamen verandert.

Nu nog even dit script in de crontab zetten en dan is ook dat weer geregeld.

ssh automatisch inloggen (2)

In een eerder bericht heb ik al gezorgd dat ik met behulp van een private key kan inloggen op verschillende servers. Ook heb ik toen een aantal alliassen aangemaakt zodat ik niet zoveel typewerk heb. Dat kan echter nog makkelijker omdat openssh daarin al voorziet in de configfiles. Je kan namelijk een naam geven aan een host en daarbij de parameters opgeven die je normaal op de commandline meegeeft. Hier kun je behoorlijk wat mee doen. Er zijn 2 mogelijke bestanden die je kunt aanpassen/bewerken. Een globale (/etc/ssh/ssh_config) of een userspecifieke (~/.ssh/config). Ik neem de laatste om mijn gegevens in te zetten, niet omdat er meerdere gebruikers zijn op mijn werksysteem maar het lijkt me wel de juiste manier.

Een mogelijke configfile:

host=host1
user=root
hostname=10.0.0.1
identityfile=~/.ssh/host1

Vervolgens kan ik inloggen met het commando ssh host1.

Je kunt trouwens elke variabele die je het commando ssh kunt geven in de configfile stoppen. Een afwijkende poort of iets dergelijks is dus ook geen probleem. Voor een overzicht zie de man-pagina