Příspěvky

4411

Software / Re:Zmazanie súboru s bodkami a medzerami v názve

« kdy: 17. 06. 2016, 08:21:47 »

Nie je to ziadna HW chyba,je to bezne spravanie ked ma subor v nazve medzery..

Proč píšete takové bludy? „input/output error“ je chyba, která obvykle znamená chybu souborového systému, která nejčastěji bude způsobená problémem s hardwarem. rm vůbec nezajímá, zda má soubor v názvu mezery – prostě dostane název souboru ke smazání, a ten soubor buď existuje nebo neexistuje. Když někdo neumí správně předat jako parametr název souboru s mezerami, předá název neexistujícího souboru a rm napíše chybu, že soubor nelze smazat, protože neexistuje (když bude mít dotyčný smůlu, trefí se tím svým názvem do jiného souboru/ů nebo adresáře/ů – a když úplně zbytečně použije parametry -r -f, může být docela veselo).

Spravne riesenie uz bolo napisane

Ano, správné řešení už jsem nejen já napsal, psal jsem i to, že v shellu je nejsnazší tabulátorem si nechat ten správný název doplnit. Ale ukázalo se, že primární problém u tazatele nebyl v té mezeře v názvu souboru, ale v nějaké chybě souborového systému nebo hardware.

4412

Software / Re:Bidirectorial rsync s vlastnou hash funkciou

« kdy: 16. 06. 2016, 07:15:29 »

Existující verzovací systémy mohou bez problému evidovat i přesuny binárních souborů.

To ano, ale už si neporadí s efektivním přenosem těch binárních souborů přes síť, a dokonce ani s jejich uložením. Resp. nevím o žádném verzovacím systému, který by ukládal jen rozdíly binárních souborů podobným způsobem,  jako je rsync přenáší přes síť.

4413

Software / Re:bidirectorial rsync s vlastnou hash funkciou

« kdy: 15. 06. 2016, 16:32:49 »

Jinou hashovací funkci nepotřebujete. Rsync pozná, že se soubor změnil (primárně podle data změny), zdrojový soubor rozdělí na bloky, spočítá jejich hash, a pak na cílovém serveru hledá, zda v cílovém souboru není blok se stejným hashem. Pokud ano, použije daný blok, pokud ne, přenese daný blok ze zdrojového souboru. Pokud tedy změníte id3 tagy souboru, změní se jen jeho malá část, a rsync přenese jen blok obsahující tuto část souboru. Tohle přenášení pouze změněných částí je důvod, proč rsync vznikl.

Oboustranná synchronizace by také neměl být problém, ale musí vám jít na obou stranách správně hodiny, aby rsync poznal, co je novější verze. A samozřejmě rsync nepozná konfliktní změny, použije vždy novější verzi – musíte si pohlídat, abyste jeden soubor neměnil na obou stranách různým způsobem.

To přesouvání souborů zkuste řešit parametrem --fuzzy a souvisejícími, ale s tím bude mít problém každý systém, který vidí jenom aktuální obraz souborového systému. Řešil by to nějaký verzovací systém, který přesuny souborů sleduje – ale nenapadá mne žádný určený pro binární soubory.

4414

Software / Re:Zmazanie súboru s bodkami a medzerami v názve

« kdy: 15. 06. 2016, 09:26:40 »

Dakujem za snahu, nemal som nervy na jeden subor - vsetko som zazalohoval, naformatoval a znovu nakopiroval.
Ospravedlnujem sa a este raz dakujem za snahu o pomoc.

Pokud to byla hardwarová chyba (jako že tomu vše nasvědčuje, není důvod, aby jeden soubor z mnoha nějakým záhadným způsobem získal třeba na ext4 atribut „i“), možná jste právě vyrazil na cestu ke ztrátě dat. Opravdu bych nechal udělat podrobný SMART test disku, ať na případný problém přijdete, dokud máte data zazálohovaná. A obecně je dobré zálohovat průběžně, ne jen když potřebujete zformátovat disk.

4415

Software / Re:Zmazanie suboru s bodkami a medzerami v nazve

« kdy: 14. 06. 2016, 12:41:15 »

Este som zabudol, s rm 2016-06-12<Tab> doplni shell toto rm 2016-06-12\ 17.01.34.jpg
a nasleduje chybove hlasenie:
rm: cannot remove '2016-06-12 17.01.34.jpg': No such file or directory.

Shell tu mezeru escapoval správně. Jste si opravdu jist, že tam ten soubor je?
Co se stane, když se na něj podíváte a pokusíte ho smazat pomocí mc?

Navíc je to jiný soubor, než který Bubo uváděl dříve.

Celé je to nějaké podivné, tazatel se soustředil na tečku a mezeru v názvu, a k tomu poskytl relevantní informace. Ale v tečce a mezeře problém evidentně není, problém je v něčem jiném, a abychom dokázali poradit, potřebujeme znát širší kontext – jak k souborům Bubo přistupuje (je to lokální systém nebo nějaký síťový disk), jak je to s právy, zda něco nehlásí do logu jádro…

4416

Software / Re:Zmazanie súboru s bodkami a medzerami v názve

« kdy: 13. 06. 2016, 15:01:15 »

Pro smazání souboru nejsou podstatná práva na tom souboru, ale je potřeba právo zápisu do nadřazeného adresáře.

Každopádně „input/output error“ ukazuje na problém se souborovým systémem nebo hardwarem. Co je to za souborový systém? Mažete to přímo na tom serveru, nebo to máte třeba přes Sambu připojené na vzdálený počítač? Když se to pokusíte smazat a vypíše to tuhle chybu, neobjeví se něco v logu výpisů z jádra (dmesg)?

4417

Software / Re:Zmazanie suboru s bodkami a medzerami v nazve

« kdy: 12. 06. 2016, 13:59:51 »

Tečky v názvu ničemu nevadí. Parametry -r a -f jste u rm použil úplně zbytečně ¨když nevíte, co dělají, tak je nepoužívejte. Input/output error vypadá spíš na problém s diskem, lepší by bylo, kdybyste sem vložil přesnou chybovou hlášku. Každopádně problém s „divnými“ znaky v názvu (může to být např. pevná mezera nebo pomlčka místo spojovníku) vyřešíte nejjednodušeji tak, že necháte název doplnit shell – on už se o správné escapování postará. Takže zadejte

Kód: [Vybrat]

rm 2016-06-12<Tab>

a shell vám název souboru doplní, nebo nabídne varianty. Pokud by nedoplnil nic, je špatně už ten začátek názvu, asi tam místo spojovníků budou jiné znaky. Pak zkuste tabulátor už po tom „2016“.

4418

Server / Re:NFS sdílení pro konkrétního uživatele

« kdy: 09. 06. 2016, 16:59:46 »

NFS je na rozdíl od Samby víceuživatelské, tj. do lokálního adresáře se připojí celý vzdálený disk nebo adresář, a v lokálním umístění pak uživatelé vidí (a aplikují se) ta stejná uživatelská práva, jako na vzdáleném serveru. Takže když třeba vzdálený disk připojíte do adresáře /mnt/webserver, můžou do toho adresáři všichni uživatelé lokálního počítače, a každý tam bude pracovat se svým oprávněním. To je rozdíl oproti Sambě, tam si uživatel připojí pod svým jménem a heslem svůj vzdálený disk, a když chce někdo na tom samém počítači pracovat se stejným vzdáleným diskem, musí si ho připojit znovu pod svým účtem – Samba je z pohledu klienta jednouživatelská.

V případě NFS to ale samozřejmě znamená, že server musí něco vědět o klientských účtech (kdyby si mohl kdokoli připojit vzdálený disk přes NFS, prohlásil by o sobě „já jsem Karel“ a server mu to zbaštil, nebylo by to moc bezpečné). Ve starších verzích protokolu to vyžadovalo, aby na serveru i klientovi měli uživatelé stejná ID, později přibyla možnost mapování jmen – v obou případech to musel root nastavit, že to takhle opravdu souhlasí a že server může ID nebo jménům z daného klienta důvěřovat. V NFS verze 4 už je to o něco menší otrava, zejména pokud používáte pro ověřování uživatelů Kerberos, mělo by být zprovoznění relativně jednoduché. Nejlepší je najít si návod pro vaši konkrétní distribuci.

4419

Vývoj / Re:Algoritmus pro skládání kousků dřeva

« kdy: 09. 06. 2016, 10:50:11 »

V tom případě by mohl algoritmus vypadat následovně (opět je jen lineární obvykle fungující implementace v případě "rozumné" distribuce dílků):

1. Nadefinovat left=0 (levá hranice), right=0 (pravá hranice), current=0 (aktuální pozice konce)
2. Vzít následující element, porovnat current-element-left a current+element-right a podle toho, který z nich bude větší, umístit element doleva či doprava. Minimalizuje buď přesah nebo není-li žádný, maximalizuje prostor pro další krok
3. Podle předchozího kroku upravit current = current+-element a pokud překročí left/right hranice, tak i ty
4. Loop to (2) until input empty

Protipříklad:
Váš algoritmus: 1-3+1+4=5
Správné řešení: 1-3-1+4=4

4420

Server / Re:Kam umístit soukromý e-mail?

« kdy: 08. 06. 2016, 16:49:05 »

Záleží, před kým se snaží chránit.

Například před ztrátou dat, bez toho bych to řešení nenazýval bezpečné.

4421

Server / Re:Kam umístit soukromý e-mail?

« kdy: 08. 06. 2016, 13:50:13 »

Zmena portu vetsinou konec utoku znamena. Vetsina utoku je automaticka a z uspornych duvodu neskanuji z kazde ip vsechny porty, ale jen ty dolni nebo jeste spise jen ty, ktere je zajimaji nebo ty, na kterych jedou zname sluzby. Kdyz tedy ssh presunu z 22 na treba 7689, tak jim domaci router na scan portu 22 ani neodpovi a portu 7689 se nikdo temer s jistotou nedotkne. Presunuti sluzby na jiny port na 1023 zpusobi v logach temer absolutni ticho.

Změna portu neznamená, že na vás přestanou útočit. On ten útočník předem nemůže vědět, že na daném portu nic není. Takže zkusí navázat spojení za účelem napadení serveru – a to už je ten útok. Akorát v případě, že služba není na daném portu dostupné, skončí útok už tím, že se nepodaří navázat spojení; pokud tam služba dostupná je, skončí útok například kvůli nepodporované metodě přihlášení.

Presunuti sluzby na jiny port na 1023 zpusobi v logach temer absolutni ticho.

To, že útoky nelogujete, neznamená, že neexistují.

4422

Server / Re:Kam umístit soukromý e-mail?

« kdy: 08. 06. 2016, 12:50:18 »

Je jasné, že pokud chci mít doma server, default porty se musí zmenit

Mně to jasné není.

Navíc změna portů neznamená, že na vás přestanou útočit. Akorát o těch útocích nejspíš nevíte a útok skončí v dřívější fázi (už při navázání spojení).

Pokud necháváte servery v defaultu (porty) tak se nedivím, že jste / byl jste snadnou "kořistí"

Snadnou kořistí je spíš ten, kdo si myslí, že změna portů nějak pomůže proti útokům.

Urcite sa k nemu niekto pokusa naburat. Nevidel som verejnu pevnu IP(presnejsie IPv4), na ktoru by sa niekto nechcel naburat.

Jistěže se mu někdo pokouší na server dostat. Jenže on před tím zavře oči, a tím problém „vyřešil“.

4423

Server / Re:Kam umístit soukromý e-mail?

« kdy: 08. 06. 2016, 10:55:47 »

90% počítačů co rozesílá SPAM je někde hostovaná VPSka někde u Wedosu atd, kterou si člověk sysadminem nepolíbený koupí místo hostingu, podle návodu na netu nainstaluje a hodi Wordpress pro svůj blogíček :-)

Takže jsou to počítače, jejichž administrátoři nevědí, že jejich počítač rozesílá spam, a do diskusí případně píšou „neřekl bych, že můj počítač rozesílá spam“.

4424

Server / Re:Kam umístit soukromý e-mail?

« kdy: 08. 06. 2016, 10:23:56 »

Nemyslíte si snad, že admin by neprišel na to, že mu jeho sever rozesilá spam nebo že mu na něj někdo útočí, že ne?

Jak si tedy vysvětlujete ty počítače, které spam rozesílají? Podle vás o tom problému admin ví, neřeší to a ještě se chlubí tím, že jeho počítač rozesílá spam?

4425

Server / Re:Kam umístit soukromý e-mail?

« kdy: 08. 06. 2016, 10:02:59 »

neřekl bych, že mi […] rozesílá spam 

To tvrdí drtivá většina těch, jejichž počítače spam rozesílají. Lidí, jejichž počítače rozesílají spam, oni o tom vědí a ještě to otevření přiznají, je minimum.