Permalänk
Medlem
Skrivet av Gix:

Om du vill ha kryptering på FTP-sessionen så har FileZilla Server stöd för TFTP (FTP over TLS).

TFTP är inte krypterat.
http://en.wikipedia.org/wiki/FTPS ... FTPS är däremot FTP over TLS.

Visa signatur

WS: Asus P8Z77-I Deluxe mITX | Intel 3770K@4.6 | NH-U12P | Asus 780 GTX | Corsair 2x8GB 1600Mhz CL9 | Samsung 840 512GB | Ubuntu 16.04.3 x86_64 | Corsair AX750 | 2x Dell U2412M | Puppe.se | NAS: i7 860, 16GB DDR3, GA-P55M-UD4, FD Define R3, 8x2TB Samsung F4EG, Serveraid M1015, EVGA 750W G2 PSU, FreeBSD x64

Permalänk
SpelClockers
Skrivet av Schrimp:

TFTP är inte krypterat.
http://en.wikipedia.org/wiki/FTPS ... FTPS är däremot FTP over TLS.

My bad, det är givetvis FTPS jag menar och inte TFTP. Redigerat mitt förra inlägg. Tack!

Permalänk
Medlem
Skrivet av phz:

Du kan använda variabler för att "minnas" namn och liknande enklare. Även funktioner kan generellt vara smidiga. Rigoröst kommenterad prototyp följer; se till att läsa och förstå innan den används (inte minst `find`-raden som raderar filer), och notera också att det är helt otestat från mitt håll:

#!/bin/sh BACKUP_PATH="/home/mc/backups" MC_PATH="/home/mc/mc/Minecraft" TGZ_FILE="backup_$(date +%Y%m%d_%H%M%S).tar.gz" SCREEN_NAME="MC" # När man börjar upprepa sig så är det ofta bra att skapa en funktion så att # man undviker skrivfel och samtidigt håller skriptet mer lättläst. mc_cmd() { # Man får hålla tungan rätt i mun för att hänga med i hur # citationstecknen fungerar här, men det ska vara all right för # närvarande. $1 är helt enkelt det första argumentet när funktionen # kallas. screen -S "$SCREEN_NAME" -X eval 'stuff "/'"$1"'\015"' } mc_cmd save-off mc_cmd save-all tar cpzf "$BACKUP_PATH/$TGZ_FILE" "$MC_PATH" mc_cmd save-on # Denna bit ser inte speciellt robust ut i mina ögon. Man ska alltid vara # defensiv när det gäller att skicka filnamn genom pipes, då filnamn _kan_ # innehålla saker som kan överraska (exempelvis radbrytningar och annat). Även # om man "vet" att de inte gör det så är det inte bra praxis att lära sig # olater, när det finns mer robusta sätt tillgängliga. Ersätt hellre med # exempelvis `find` som rensar allt äldre än 24 dagar (här baserat på dess # datumstämpel snarare än dess filnamn), om det är det du vill. #cd /home/mc/backups #ls -t | sed -e '1,24d' | xargs -d '\n' rm find "$BACKUP_PATH" -mindepth 1 -mtime +24 -delete # Läs `man find` för att se vad ovanstående kommando gör! # Filuppladdning löses troligen enklare om du har ett shellkonto någonstans och # kan köra `rsync` som nämndes tidigare i tråden, men det är också lösbart # genom FTP. # # Så som du har skrivit nu är inte vettigt dock. Varje rad i ett shellskript # exekveras av tolken, så det som du tror hanteras av FTP-programmet # försöker skalet i stället köra som kommandon, vilket lär ge en del # felmeddelanden i bästa fall, och göra något oväntat i sämsta fall. # # Det är dock nästan möjligt att göra som du skriver, men kommandona behöver # skickas in som en sträng. Vi kan göra det med "heredoc"-syntax: #ftp <<EOF #open minip #user mittanv mittlösenord #put "$BACKUP_PATH/$TGZ_FILE" #EOF # Alternativt kan man här använda Curl: curl --upload-file "$BACKUP_PATH/$TGZ_FILE" ftp://minip --user mittanv:mittlösenord # Om detta körs på en "delad dator" så finns det en säkerhetsbrist i att ange # inloggningsuppgifter direkt på kommandoraden. Bättre är att använda en fil # med dessa uppgifter lagrade; se växeln `-n` till Curl för att använda # `~/.netrc` till detta (denna fil går även att använda för `ftp`). # # Man kan även titta på `lftp` och `ncftp` om man vill göra mer avancerade # saker över FTP. # # Notera att det allmänt är lite vanskligt att behöva ange lösenord i klartext, # och FTP är på egen hand väldigt osäkert. Vanligare är att använda # SSH-inloggning med nycklar, om nu fjärrservern man vill köra backup till är # en "vettig dator" som förstår SSH :-) .

Om du tar bort `-delete` från `find`-kommandot så bara skrivs de filer som skulle ha tagits bort ut. Använd detta för att säkerställa att raden gör vad du vill. Notera att det blir fullständigt kaos om du av någon anledning skulle lämna variabeln `BACKUP_PATH` tom, så gör inte det. Kanske du till och med borde ha en extrakontroll innan `find`-raden som säkerställer att du angett en giltig katalog där, typ:

if ! [ -d "$BACKUP_PATH" ]; then printf '%s: fel: "%s" är inte en giltig katalog! Avbryter.\n' "${0##*/}" "$BACKUP_PATH" 1>&2 exit 2 fi find "$BACKUP_PATH" -mindepth 1 -mtime +24 -delete

Det skadar inte att vara defensiv när det handlar om kommandon som exempelvis raderar filer eller på andra sätt kan förändra saker till det sämre.

Jag får inte find "$BACKUP_PATH" -mindepth 1 -mtime +24 -delete att fungera, någon ide?

Permalänk
Hedersmedlem
Skrivet av anonymous:

Jag får inte find "$BACKUP_PATH" -mindepth 1 -mtime +24 -delete att fungera, någon ide?

Tips först och främst så att inget går fel: ta bort `-delete` när du undersöker kommandot. Då skrivs bara filnamnen ut för de filer som träffar snarare än att de samtidigt tas bort.

`-mtime +24` träffar alla filer som modifierats senast för 24 dagar sedan eller mer (det var vad jag gissade att du försökte göra med din tidigare `sed`-rad). Möjligen (troligen) har du inga sådana filer i katalogen, varpå `find` inte hittar någonting och därmed inte verkar göra någonting. Generellt så betyder "inget svar" av kommandon i *nix ofta "det fungerade som det skulle, så jag har ingen anledning att säga något", så förvänta dig ingen output om du inte ber om det.

`-mtime` bryr sig alltså inte om filnamn, utan bara vilken stämpel filerna har på filsystemet. Eftersom dina .tar.gz-filer senast ändrades just när de skrevs (för det finns ju inte mycket poäng i att ändra dess innehåll därefter) så spelar detta här i praktiken ingen roll: `find` träffar helt enkelt de filer som skrevs för 24 dagar sedan eller mer.

Läs `man find` för mer information om vad `find` gör. Det är en massiv manualsida, så man får lära sig att söka efter intressanta bitar.

Du kan här även ha nytta av `-type f` då du bara vill matcha filer (inte kataloger) och kanske även `-maxdepth 1` för att inte fortsätta söka i underkataloger till argumentet, om du skulle ha några sådana. De bör då enklast ges i ordningen:

find "$BACKUP_PATH" -mindepth 1 -maxdepth 1 -type f -mtime +24 -delete

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem
Skrivet av phz:

Tips först och främst så att inget går fel: ta bort `-delete` när du undersöker kommandot. Då skrivs bara filnamnen ut för de filer som träffar snarare än att de samtidigt tas bort.

`-mtime +24` träffar alla filer som modifierats senast för 24 dagar sedan eller mer (det var vad jag gissade att du försökte göra med din tidigare `sed`-rad). Möjligen (troligen) har du inga sådana filer i katalogen, varpå `find` inte hittar någonting och därmed inte verkar göra någonting. Generellt så betyder "inget svar" av kommandon i *nix ofta "det fungerade som det skulle, så jag har ingen anledning att säga något", så förvänta dig ingen output om du inte ber om det.

`-mtime` bryr sig alltså inte om filnamn, utan bara vilken stämpel filerna har på filsystemet. Eftersom dina .tar.gz-filer senast ändrades just när de skrevs (för det finns ju inte mycket poäng i att ändra dess innehåll därefter) så spelar detta här i praktiken ingen roll: `find` träffar helt enkelt de filer som skrevs för 24 dagar sedan eller mer.

Läs `man find` för mer information om vad `find` gör. Det är en massiv manualsida, så man får lära sig att söka efter intressanta bitar.

Du kan här även ha nytta av `-type f` då du bara vill matcha filer (inte kataloger) och kanske även `-maxdepth 1` för att inte fortsätta söka i underkataloger till argumentet, om du skulle ha några sådana. De bör då enklast ges i ordningen:

find "$BACKUP_PATH" -mindepth 1 -maxdepth 1 -type f -mtime +24 -delete

Detta är vad som kommer upp när jag kör,
http://i.imgur.com/eenvdmP.png
Detta är ls -l
http://i.imgur.com/rL9NE4q.png

Även om filerna ligger tätt så borde den väl skilja på sekunder?
Tack på förhand

Permalänk
Medlem
Skrivet av anonymous:

Detta är vad som kommer upp när jag kör,
http://i.imgur.com/eenvdmP.png
Detta är ls -l
http://i.imgur.com/rL9NE4q.png

Även om filerna ligger tätt så borde den väl skilja på sekunder?
Tack på förhand

Tror jag hittade problemet
-mmin n
File's data was last modified n minutes ago.
-mtime n
File's data was last modified n*24 hours ago.
Att där finns ju inga 24 timmar precis

Permalänk
Hedersmedlem
Skrivet av anonymous:

Tror jag hittade problemet
-mmin n
File's data was last modified n minutes ago.
-mtime n
File's data was last modified n*24 hours ago.
Att där finns ju inga 24 timmar precis

Precis, `find` med `-mtime +24` träffar som sagt de filer som modifierats för 24 dagar sedan eller mer. Vill du ha något annat tidskrav är det bara att använda något annat. 24 dagar vad som jag skrev innan en ren gissning utifrån vad du verkade vilja göra med din tidigare `sed`-dans.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem
Skrivet av phz:

Precis, `find` med `-mtime +24` träffar som sagt de filer som modifierats för 24 dagar sedan eller mer. Vill du ha något annat tidskrav är det bara att använda något annat. 24 dagar vad som jag skrev innan en ren gissning utifrån vad du verkade vilja göra med din tidigare `sed`-dans.

Skriptet köra en gång i timmen, altså
00.00
01:00
02:00
osv
så på ett dygn kommer den skapa 23 filer
I mappen ska där va totalt 23 filer.
Den 24de filen ska ersättas med den som va första filen.
alltså 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23
när den 24de filen skapas ska det bli såhär
2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24
där finns fortfarande 23 filer men den äldsta har raderats
Och vad jag fattar så gör inte -mtime 24 detta

Permalänk
Hedersmedlem
Skrivet av anonymous:

Skriptet köra en gång i timmen, altså
00.00
01:00
02:00
osv
så på ett dygn kommer den skapa 23 filer
I mappen ska där va totalt 23 filer.
Den 24de filen ska ersättas med den som va första filen.
alltså 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23
när den 24de filen skapas ska det bli såhär
2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24
där finns fortfarande 23 filer men den äldsta har raderats
Och vad jag fattar så gör inte -mtime 24 detta

Du tidsstämplar enligt tidigare filerna med "YYYYmmdd_HHMMSS", så det blir inga namnmässiga kollisioner. I stället för att ta bort filer äldre än 24 dagar så vill du snarare då ta bort filer äldre än 24 timmar. Man kan notera att det är 24 timmar är samma sak som 1 dag, så `-mtime +1` borde väl duga hyfsat. Vill du ha annan tidsgranularitet så finns det en mängd andra växlar att använda i `find`.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
SpelClockers
Skrivet av phz:

Du tidsstämplar enligt tidigare filerna med "YYYYmmdd_HHMMSS", så det blir inga namnmässiga kollisioner. I stället för att ta bort filer äldre än 24 dagar så vill du snarare då ta bort filer äldre än 24 timmar. Man kan notera att det är 24 timmar är samma sak som 1 dag, så `-mtime +1` borde väl duga hyfsat. Vill du ha annan tidsgranularitet så finns det en mängd andra växlar att använda i `find`.

Det är bra tänkt, men -mtime n fungerar inte riktigt så. n står för hur många 24-timmarsperioder som gått sedan filen senast modifierades. Tiden räknas enbart i heltal och avrundas alltid nedåt.

0 dagar, 23 timmar och 59 minuter kommer att avrundas nedåt till 0.
1 dagar, 0 timmar och 0 minuter kommer att avrundas till 1.
1 dagar, 23 timmar och 59 minuter kommer att avrundas nedåt till 1.
2 dagar, 0 timmar och 0 minuter kommer att avrundas till 2.

Om man anger argumentet +1 så betyder det att filen måste vara äldre än 1*24 timmar, det vill säga 2 dagar givet räkneexemplet ovan. För att matcha filer äldre än 24 timmar så behöver man ange argumentet +0 (åter se räkneexemplet ovan).

Om man vill ha mer exakthet så finns flaggan -mmin som räknar på minuter. -mmin följer fortfarande samma logik som ovan. 1 minuter och 59 sekunder kommer fortfarande betraktas som 1 minut.

Permalänk
Hedersmedlem
Skrivet av Gix:

Det är bra tänkt, men -mtime n fungerar inte riktigt så. n står för hur många 24-timmarsperioder som gått sedan filen senast modifierades. Tiden räknas enbart i heltal och avrundas alltid nedåt.

0 dagar, 23 timmar och 59 minuter kommer att avrundas nedåt till 0.
1 dagar, 0 timmar och 0 minuter kommer att avrundas till 1.
1 dagar, 23 timmar och 59 minuter kommer att avrundas nedåt till 1.
2 dagar, 0 timmar och 0 minuter kommer att avrundas till 2.

Om man anger argumentet +1 så betyder det att filen måste vara äldre än 1*24 timmar, det vill säga 2 dagar givet räkneexemplet ovan. För att matcha filer äldre än 24 timmar så behöver man ange argumentet +0 (åter se räkneexemplet ovan).

Om man vill ha mer exakthet så finns flaggan -mmin som räknar på minuter. -mmin följer fortfarande samma logik som ovan. 1 minuter och 59 sekunder kommer fortfarande betraktas som 1 minut.

Korrekt, ett klassiskt "off-by-one error". Detta står också som exempel i `man find` (för `atime`, med notis att samma regler gäller för `mtime`):

Citat:

File was last accessed n*24 hours ago. When find figures out how many 24-hour periods ago the file was last accessed, any fractional part is ignored, so to match -atime +1, a file has to have been accessed at least two days ago.

Vilken exakt implementation som passar trådskaparen lämnas som sagt öppet till testkörningar med olika växlar och en fin stund med `man find` . Att lära sig använda manualen är en minst lika viktig övning som att lära sig att använda `find`.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.