Názory k článku Konec protokolu scp: plný děr a neopravitelný, ale uživatelsky příjemný

Možná by bylo zajímavé udělat anketu co lidi na přenášení souborů používají. Já se přiznám, že scp vůbec nepoužívám. Když instaluji server, tak mezi prvními věcmi co tam nacpu je rsync. scp má při rekurzivním kopírování strašnou režii a ve chvíli kdy nemám rsync (openwrt apod), tak nemám problém napsat pipe tar -f - soubory | ssh nekam tar -C kam -xf -... Ale určitě +1, za udržení kompatibility.

Taky to není nástroj na přenášení složitých stromů ale kopírování one-line příkazem pár souborů sem nebo tam z nebo na vzdálené servery.

U zakose jsem potreboval povolit bezpecne kopirovani dat, ale zabranit prihlaseni do systemu a vrtani se v nastaveni (obcas bohuzel znaji admin hesla).

Kombinace restricted shell (tam by to chtelo take zapracovat) a sftp per user group to vyresila.

Osobne mam nejvetsi problem s scp pri kopirovani dat z win ntb over vpn. Scp tam po par mb zacne brutalne zpomalovat, sftp stejnym problemem netrpi. Sftp navic umi "reget".

Jinak na pravidelne ci automaticke kopirovani stejne pouzivam rsync, cili bez scp bych se asi obesel. Pro synchronizaci dat se scp taky nehodi.

Mozna teda pouzit misto scp rovnou rsync, a naucit ho novym prepinacem mod kompatibilni s scp options ?

Jak to sftp používáš? To jeho CLI interface je prostě insane (a to jsem fakt nenáročný: zkopírovat soubor a zkopírovat adresář rekurzivně) - efektivně to neumí zadat uvedené jako parametry, musí se to dělat v interaktivním módu (nebo do toho příkazy napajpovat). To abych si napsal shellový wrapper. A to je podle mě důvod, proč to nikdo nepoužívá. scp má i další problémy (například když se kopíruje spousta malých souborů, tak to má, zdá se, pro každý soubor konstantní latenci).

Jakože „nejjednodušší“ použití sftp je asi sftp <<<'put soubor' jenda@stroj:/tmp. No divíte se?

Pro rsync mám následující alias alias rse='rsync --numeric-ids --inplace -avzhPe ssh' a pokryje to všechna moje použití. Ale třeba na openwrt není rsync defaultně (a ten co se tam dá doinstalovat se musí používat s parametrem -zz, protože neumí tu -z komprezi) a v „minimálních“ instalacích některých distribucí taky ne.

Nie, fakt, vazne, ... to je take tazke opravit kopirovanie suborov? Pozeram tie zranitelnosti a nechce sa mi verit ze je tazke postrazit zopar suborov a pridat rekurzivny switch.

Bohužel se ukazuje, že mnohé projekty, na kterých stojí v podstatě celá informační společnost (openssl, gnupg, curl, zjevně sftp/scp), jsou kdesi v pozadí a nikdo se jim nevěnuje. https://www.explainxkcd.com/wiki/index.php/2347

Jsem dnes nějaký zpomalený a nerozumím Tvé větě „...jsou kdesi v pozadí a nikdo se jim nevěnuje.“ Mohl bys mi vysvětlit, jak to myslíš? Nemám totiž pocit, že by nikdo nevěnoval svoji pozornost vývoji/správě těchto projektů... Nebo to myslíš tak, že diskuzi o těchto problémech nevedeš v rubrice krimi na Novinkách?

Jen v případě scp někdo řekl, tak už dost, to musíme udělat znovu a lépe a někdo jiný něco udělal... Tak v čem je problém?

> Nemám totiž pocit, že by nikdo nevěnoval svoji pozornost vývoji/správě těchto projektů...

Přímo v článku, pod kterým diskutuješ, se píše o zastaralém a zabugovaném scp a obtížně použitelné náhradě, řádkovém sftp. Informace o ostatních projektech, které zmiňuji, lze snadno dohledat, ale budiž: OpenSSL Software Foundation President Steve Marquess wrote in a blog post last week that OpenSSL typically receives about $2,000 in donations a year and has just one employee who works full time on the open source code.; gnupg: 1, The software is Byzantine. The software is unmaintained.

10. 11. 2020, 11:20 editováno autorem komentáře

Jenže to, co píšeš, je vytržené z kontextu, protože v tom samém článku se píše o tom, že autoři hledají, jak z toho ven. To mi evokuje snahu o řešení problému zastaralého konceptu něčím moderním - navíc nad tím přemýšlí - a ne jako nezájem o problém.

Pokud máš pocit, že nechcou opravit existující problém, tak sice ano, ale píšou zde i proč. Prostě se SCP dostalo do stavu, kdy je třeba najít novou cestu. A to samotné rozhodnutí svědčí o zájmu.

Na druhou stranu, ano, máš pravdu, jsou klíčové projekty, které jsou dlouhodobě podhodnocené...

Tak openssl to se vyřešilo poměrně snadno pomocí https://www.libressl.org/

scp/sftp/ssh je https://www.openssh.com/ a ano, v minulosti byl mnohem větší problém s tím, že společnosti, které to využívají nic nepřispěli zpět. To už se postupně mění (až na některé Unix-like ....) a je to pěkně vidět zde https://www.openbsdfoundation.org/contributors.html , je zajimavé, že třeba Facebook nebo Microsoft tam jsou, ale proč tam nejsou nějaká známá komerční jména ze světa Linuxu je otázka k zamyšlení ;-)

Je něco jiného uplácat SW jen proto, že umím uplácat SW oproti tomu to dělat pořádně a stabilně. Vyžaduje to znalosti, čas a i dost těch peněz i u "free" projektů. Pro komerční firmy je důležitá i licence, proto má Google v Androidu z téhož místa libc, Apple firewall atd. ;-)

Za OpenSSL se staví plno firem, ale reálně peníze ani lidi nedodávají. Gnupg nebo curl jsou na tom ještě hůře, ale je to situace jako třeba u Qutebrowser, to je v podstatě taky jen jeden člověk, ale děje se tam toho poslední dobou dost, protože je sponzorovaný na part time aby na tom dělal.

Ja v tom vlastne nevidim smysl.

"Nechceme delat velke upravy programu scp, abychom nerozbili stare workflows".

"Příkaz s názvem scp ... Základní funkci už plní, ale některé volby zatím nejsou dostupné. Například kopírování mezi dvěma vzdálenými servery bez účasti klienta."

Takze novy prikaz rozbiji stare workflow, ale Fedora je happy nahradit jim program scp? Hmm... Co takhle vzit stare dobre scp a urezat mu ty nebezpecne featury typu shell expansion?

To nejsou „featury“ a nejdou „uřezat“. To je způsob, jakým je to celé naprogramované (že to něco forkuje a tak).

A ono sa neda 'preprogramovat'? Nie je to nahodou SOFTware?

Ano a přesně to se děje, protože to je software, tak ho přeprogramovávají, aby byl lepší. Přesně o tom je celý článek.

"Tvá logika je bezchybná."

Dekuji za info a jsem rad ze myslite na zachovani stavajicich scriptu.
S programovanim Vam moc nepomuzu, ale pokud narazim na problem se zpetnou kompatibilitou, rad budu reportovat.

Kuba

Ja pouzivam scp denne a diky jeho nazvu a tomu, ze je casti openssh baliku jsem si vubec nepripoustel, ze by mohl mit problemy. Predstavoval jsem si, ze funguje nad ssh.
Jinak, kopirovani stromu delam zasadne stylem
tar cvzplO . | ssh root@nekam (cd nekam && tar xpf -)
ted honem nevim, jestli jsem v tom neudelal nejaky preklep, uz jsem to dlouho nepouzival.
Jak jsem psal nahore, predstavoval jsem si, ze scp spusti neco podobneho.

Já často používal WinSCP na Windows a protokol SFTP. Je hodně programů s GUI které SFTP umí. A umí to i kompresi na pozadí. Rsync jsem používal kdysi na Linuxu. Ale podpora rsync v GUI programech jako je třeba FileZilla a další různí FTP klienti kteří umí víc protokolů bude asi horší.
A podpora na serverech například na filehostinzich také..

Osobně jsem používal do teď SFTP když to šlo a když ne tak FTPS.
Nevím jestli někdo používá třeba webdav nebo další protokoly a jaké jsou výhody a nevýhody. Možná by byl fajn článek o různých možnostech a implementacích.. :-)

Existují různé krabičky typu router, stb, ip kamera které mají očesaný systém a v baličkovacím systému je místo jen tak akorát pro to scp, přičemž ssh je implementované přes Dropbear. Nainstalovat tam sftp, pokud to jde, by znamenalo, že by se musely ubrat jiné balíčky na omezeném prostoru anebo většinou složitě rozšiřovat int.pamět (typicky přes dopájené SD rozhraní, u dražších modelů s USB o něco přímočařeji přes flashdisk).

Takže toto řešení je hezké, ale například na tato zařízení asi jentak nedorazí, teda aspoň dokud nebudou parametry interních pamětí velkorysejší. Což je u zařízení cenově dejme tomu do tisícovky běh na dlouhou trať.

OpenSSH je součástí Windows 10, takže by to moc dlouho trvat nemuselo.

Příkaz scp je navíc pevně zakořeněný v hlavách uživatelů, podobně jako dávno zastaralý příkaz ifconfig.

Možná by stálo za zamyšlení, proč tomu tak je. ifconfig je 21let zastaralý, což už je jedna celá generace. Za tu dobu jsme přešli na smartphone, dotykové ovládání a už 2x přeladili TV na novou normu. Jak je tedy možné, že 21 let zastaralý příkaz je stále "zakořenený" v hlavách adminů, od kterých by se navíc dala / měla očekávat nějaká trochu vyšší mentální aktivita?

Jinak nové scp není nic proti ničemu, pokud bude bezpečné a použitelné. Je otázkou, proč rsync velmi často chybí v minimální distribuci, ale i to se dá řešit pomocí kombinace tar a ssh.

Možná by stálo za zamyšlení, proč tomu tak je. ifconfig je 21let zastaralý, což už je jedna celá generace.

Někteří ifconfig dál používají na BSD systémech, to může být malá část důvodu.

Největší část problému je držení kompatibility. Zprvu se to nechá, aby se nerozsypaly scripty. Pak se postupně vytratí z distribucí, ale lze doinstalovat (což se stane při prvním balíku, který takovou závislost stále má).

Díky tomu se to na věky věkův udrží v návodech na internetu a v hlavách lidí. 90 % příspěvků na internetu jsou vykopírované starší návody a diskuse těch, kteří to umějí málo s těmi, kteří to umějí ještě míň.

Pochybuju, že to lze dělat o moc líp bez násilného odstranění příkazu úplně.

Kde se vzal ten názor, že ifconfig je zastaralý? Že se jeden systém rozhodl zahodit vývoj a místo toho znovuobjevit kolo, ale zároveň nechat i to staré tolik let na místě není problém ifconfig.

ifconfig = interface config

Proč je na Unix-like systémech a xBSD používán a hlavně stále aktivně vyvíjen s mnohem více funkcemi, které se týkají síťových rozhraní aby se člověk nemusel učit milion jiných příkazů je dostatečně jasné i z man stránek

https://man.openbsd.org/ifconfig

https://man.netbsd.org/ifconfig.8

https://www.ibm.com/support/knowledgecenter/ssw_aix_72/i_commands/ifconfig.html

https://docs.oracle.com/cd/E36784_01/html/E36871/ifconfig-1m.html

Mentální aktivita adminů, kteří raději používají jeden příkaz, který pokryje vše, nenutí zbytečné učení nových věcí, které nepřínášejí žádnou výhodu, když funkcionalitu je možné mít v existujícím příkazu, který je navíc udržován a vyvíjen a umožňuje interoperabilitu nebo minimálně usnadňuje přechod mezi systémy, tak tato mentální aktivita je zcela jistě v pořádku.

Naopak bych se pozastavoval nad tím jak vypadá man stránka pro ip nebo to, že stačilo udělat 'ifconfig eth0' a člověk viděl i statistiky rozhraní rovnou, což pro admina co řeší problém bylo hned na místě. Teď musí udělat například 'ip -s link' přičemž přepínač -s není ani popsán v man stránce a nelze zobrazit jen jedno konkrétní rozhraní, ale ukáže všechny. Tomu se říká pokrok?

> Teď musí udělat například 'ip -s link' přičemž přepínač -s není ani popsán v man stránce

Já ho v man ip mám. Nemám ho v man ip-link, protože je asi myšlený víc globálně?

> a nelze zobrazit jen jedno konkrétní rozhraní, ale ukáže všechny

ip -s l show dev eth0

Jo, jo. Místo toho, abych prostě napsal ifconfig eth0 má jakási firma představu, že budu psát cosi šíleného jako ip -s l show dev eth0. A proč? Co mi to přinese navíc?

Odpověď je právě jasná. Nic. A hned jsme u toho důvodu.

Kde se vzal ten názor, že ifconfig je zastaralý?

To není názor. V kernelu 2.2 došlo k tak výrazným změnám v síťování, že bylo jednodušší napsat nový nástroj a ten starý prostě nechat dožít.

kteří raději používají jeden příkaz

Jsem v praxi 15 let a s naprostou pravidelností vídávám, jak někdo použije "stejný" příkaz akorát na jiném OS a potom se diví. Někdy stačí jen jiná distribuce.

Navíc to zmíněné síťování na BSD systémech je také dost jiné, nebo i tam používáte například iptables? Asi ne, místo toho tam máte (na FreeBSD) tři různé FW.

Teď musí udělat například 'ip -s link' přičemž přepínač -s není ani popsán v man stránce a nelze zobrazit jen jedno konkrétní rozhraní, ale ukáže všechny. Tomu se říká pokrok?

Asi máte divný man. -s tam je. Stejně jako popis výběru konkrétní iface. A celý ten příkaz je strukturovaný, takže pokud se naučíte například styl práce s ip a, tak už to bude velmi podobné pro ip r, ip l atd.

V kernelu 2.2 došlo k tak výrazným změnám v síťování, že bylo jednodušší napsat nový nástroj a ten starý prostě nechat dožít.

Což byl obrovský neodhad situace. Kdyby bývali věděli, že ifconfig přežije další dvě dekády, spíš by řešili, aby ifconfig zůstal kompatibilní s rozhraním jádra.

Navíc to zmíněné síťování na BSD systémech je také dost jiné, nebo i tam používáte například iptables?

Jojo, ifconfig na FreeBSD je odlišný od linuxového. Taky ho museli hodně překopávat, doplňovat, co si doba žádala. Podle mě je to lepší praktika, než zachovat kompatibilní-ale-vlastně-nekompatibilní ifconfig a preferovat jiný nástroj. To se prostě nepovedlo, ifconfig nevymřel.

Jenže pointa je o tom, že ifconfig vznil v 4.2BSD jako i samotná TCP/IP implementace. V xBSD a Unix-like systémech je to plnohodnotný a aktivně vyvíjený a udržovaný program.

Je to věc Linuxu stavět si hlavu a trochu to připomíná Windows v dřívějších letech, ale to se nám všem jen zdá, protože Linux přece chtěl být lepší než Windows ;-)

Když už se rozhodli jak se rozhodli, tak budiž, ale ať to prezentují jak mají aneb že se rozhodli být nekompatibilní se zbytkem Unix-like světa a ať to prostě natvrdo zahodí a vnutí ip. Když to jde s systemd a podobně, tak nevidím problém u takové v podstatě prkotiny.

Tím by jsme měli vyřešenu "zastaralost", která neexistuje, protože ifconfig není Linux příkaz.

K "stejným" příkazům.... na Unix-like mám vždy ifconfig, že může být jiný počet přepínačů je už jen drobnost jako na Linuxu, kde i ip samotný je rozdílný mezi distribucemi. V práci mezi hromadou OS člověk používá to co je nativní pro ten OS, pokud to nedělá, tak v té práci nemá co dělat :-)

iptables.....brrr naštěstí ne :-D FreeBSD a 3 různé fw, z toho některý třeba pozadu oproti realitě (pf) je důsledek toho, že chtějí být jako Linux. Nic co bych mohl nějak ovlivnit, maximálně výběrem OS no

Ano, přepínač tam je jak potvrzeno v jiné mé reakci, v ip samotné. Čekal bych ho v ip-link (ale ta zase není ve všech distrech), ale to už je věc pohledu.

Jestli je toto https://www.systutorials.com/docs/linux/man/8-ip-link/ vůči tomuto https://man.openbsd.org/ifconfig , už jen od pohledu strukturované, tak máme asi jiný náhled na to co je pořádek, čitelnost a struktura. Dá se to ale chápat, když v samotném RHEL vývojaři třeba KVM považují man stránky za zbytečnost a že přece když chce někdo něco vědět, tak si přečte zdrojový kód. Pak to tak vypadá bohužel, to vede i k věcem kdy se v systému drží 20 let nedoporučovaný a neudržovaný příkaz nebo jako v OpenSSL otřesný guláš kódu pro HW, který nikdo na vlastní oči už 30 let neviděl

ať to prostě natvrdo zahodí a vnutí ip
To autoři iproute2 udělali. Ale nemohli zabránit autorům ifconfig, aby svůj program dál vyvíjeli i pro Linux. A nemohli zabránit autorům distribucí, aby balíček s ifconfig dál distribuovali v základních verzích distribucí.

Problém s ifconfig v Linuxu padá jednoznačně na hlavu autorů distribucí, ti mohou za to, že distribuce používaly ve svých skriptech nástroj, který fungoval špatně.

Ano, přepínač tam je jak potvrzeno v jiné mé reakci, v ip samotné. Čekal bych ho v ip-link (ale ta zase není ve všech distrech), ale to už je věc pohledu.

To není věc pohledu. Je to globální přepínač, ne specifický pro daný podpříkaz. Proto se také píše před link a ne až za něj a proto je dokumentovaný v ip(8) a ne v ip-link(8).

Já používám ifconfig občas když chci vidět, kolik dat proteklo. ip -s l mi řekne 1069810211 - tak dík, teď abych si odpočítával, kolik je to číslic. ifconfig mi řekne 1020.2 MiB. Jinak samozřejmě jakoukoli konfiguraci a další věcí dělám pouze pomocí ip.

ip stejně, jako většina dalších programů co zobrazují čísla zná i parametr -h

To mě nenapadlo, díky :).

Mimochodem když už jsme u toho, tak má taky parametry -br (kratší výpis), -c (obarvený) a -j (json! takže se nemusíte snažit grepovat „druhé slovo na třetím řádku“)

V které verzi a kterém OS (nebo teda distru) to takhle má?

Jj neni nad to mit treba:

$ netstat -bh -I em0
Name    Mtu   Network     Address               Ibytes     Obytes
em0     1500  <Link>      08:00:27:1c:12:5a      16.5M       134M
em0     1500  10.0.2/24   10.0.2.15              16.5M       134M
em0     1500  fe80::%em0/ fe80::a00:27ff:fe      16.5M       134M

-b jako bytes
-h jako human readable
-I jako interface

K tomu běžně používám ip, jak psali kolegové, je možné použít u statistik parametr  -h:

# ip -s -h link show dev enp1s0

Pokud chci všechna rozhraní, vynechám poslední tři argumenty.

Zatímco předtím stačilo


ifconfig enpls0


tak teď je k tomu třeba 5 dalších parametrů navíc. Jako admin hledám nejkratší cestu, obzvláště když se to dělá často.

Dá se na to ale určitě zvyknout, jen toho zbytečného psaní navic.

Více zarážející je ta nekonzistence celková. V RedHat 6 je manuálová stránka pro ip kde je zmíněný -s přepínač, ale není tam manuálová stránka pro ip-link, ta už je v RedHat 7, ale zmínka o přepínači -s v ní není a je jen v ip samotném

Pomocí ip -s a s team2 dosáhnu podobného výstupu jako s ifconfig, ale nejsou tam jednotky převáděné, abych toho dosáhl tak nemůžu použít ip -sh a s team2 (protože z nějakého důvodu se rozhodli nenaprogramovat spojování přepínačů), ale musím použít ip -s -h a s team2.

ip -s -h l ;)

Jo dřív to bylo takové jednodušší. Ipconfig ve win, ifconfig v linuxu. Teď se to už pamatovat nedá a musí se hledat, co vlastně mám napsat. A eth0 už taky není co bývalo.

To je hodně dávné „dřív“. Příkaz ip je tu s námi od roku 1999 a naopak poslední verze ifconfig pro Linux vyšla v roce 2001. Zhruba od té doby se považuje původní příkaz za zastaralý, protože používá už neexistující rozhraní jádra (dnes je jen emulované) a umí ukazovat nesmysly.

Třeba nepočítá s více adresami na rozhraní (ukazuje je jako separátní rozhraní), nedovoluje libovolně pojmenovat síťové rozhraní, neumí masky pomocí zápisu CIDR, neumí barvičky a podobně. Navíc tyhle staré utility čtou výstupy z /proc/, místo aby používaly dnešní rozhraní netlink pomocí socketu.

Balíček net-tools už dávno není ve výchozím stavu v distribucích instalován a je potřeba si o něj explicitně říct. Tohle už fakt nechcete používat.

Tak stale sa mozes vratit k eth0 pomocou 'biosdevname=0' ako parameter jadra, pripadne si to upravit po svojom v '/etc/udev/ru­les.d/70-persistent-net.rules' - ta cesta ale na sto percent plati pre redhat a spol, inde somsi nie isty...

Jsem na světě 33 let, stačil jsem se toho naučit ohledně Linuxu spoustu a u něčeho jsem byl nucen vše zapomneout a naučit se znovu jednou, u něčeho dvakrát.

Překopává se naprosto všechno a pořád a je to únavné, člověk z těch knih nemůže zvednout hlavu, v tu chvíli už používá něco, co je obsolete. Nechci to umět "tak nějak", ale pořádně.

Tak se naučím se scp, místo toto mám používat sftp. Naučím se SysV, mám používat Systemd, naučím se s network-managerem, v tu chvíli mi tam nacpou neplan, naučím se s ifconfig, najednou je to ip. To je prostě trochu problém, člověk se potřebuje občas učit i něco jiného, než to co se už jednou bezpečně naučil.

Tak ještě že tu máme ten POSIX.
Takový RSX-11 nebo MR12.3, to byste si užil.

Ale občas se i ty "staré páky" hodí. Nedávno jsem klonoval pár počítačů a připojoval jsem je nekříženým UTP kabelem na přímo do dvojic.
S "novým ip" se mi vůbec nedařilo to rozběhnout a se stařičkým ifconfigem to šlo na první dobrou.

Docela výstižně to řekl Buzz Aldrin

https://blog.speculist.com/wp-content/uploads/2012/10/buzzonMITreview.jpg

You promised me Mars colonies. Instead, I got Facebook.
We've stopped solving big problems.

Nejde jen o to naučit se něco nového. Problém je v tom, že to nové má potenciálně horší ergonomii a/nebo neumí vše, co uměla ta původní varianta. Jestliže je původní utilita intuitivní pro jednoduché použití a ta "lepší" má (zejména pro interaktivní práci) mimoňské ovládání nebo neumí poměrně základní operace, které zvládala ta původní, není divu, že se lidem do změny nechce.

Možná změnit přístup k věci. Jestli se opravdu musíte učit něco skutečně nového při přechodu mezi scp a sftp, tak je to nějaké divné. Obé slouží jen k přenosu souborů, to lze řešit mnoha různými způsoby. Někdy se třeba hodí i obyčejný nc, pokud kupříkladu potřebuju udělat image něčeho fakt pomalého, co by nestíhalo šifrovat. Tj boot z flashky, vytvořit nc server na zálohovacím stroji a na zálohovaném udělat prosté pv /dev/sda | nc server port. Jinde stačí klasické ssh. Pro více souborů je tady efektivní rsync a pokud není, tak tar | ssh.

Prostě ten problém se nejmenuje "scp", ten problém se jmenuje "přenést data", což lze udělat mnoha způsoby a každý se hodí na jinou situaci.

Ale pokud vám ty změny skutečně vadí, tak za sebe doporučuju FreeBSD. Base systém funguje, je stabilní, příliš se nemění, nepoužívají ani GNU verze, ale pěkně staré unixové, má to skvělou dokumentaci, je to pohoda.

neplan

No to je největší kravina za posledních x let. Je to zcela zbytečná vrstva navíc. Úkol zní nastavit síť. Od toho slouží rozhraní jádra a třeba zmíněný příkaz ip. Dřív se to tak i v některých distrech nastavovalo, člověk psal přímo příkazy pro ip. Nad tímto se postavila další vrstva (NM, systemd-networkd), která ještě dává smysl, sjednocuje konfiguraci do souborů, umí reagovat na události apod. Potud je to v pořádku.

Ale potom někdo vymyslí další vrstvu, která jen mění způsob konfigurace a jako "renderer" si volí právě NM nebo networkd. Ale vůbec nic to neulehčuje, protože v případě problémů člověk stejně tak jako tak musí znát jak ten netplan, tak tu nativní službu pod tím a stejně tak i ip.

Ale pokud vám ty změny skutečně vadí, tak za sebe doporučuju FreeBSD. Base systém funguje, je stabilní, příliš se nemění, nepoužívají ani GNU verze, ale pěkně staré unixové, má to skvělou dokumentaci, je to pohoda.

Mně třeba změny nevadí, ale opravdu je někdy neúčelné se jim poddávat. Pokud potřebuji nastavit obyčejný server, jsou schopnosti ifconfigu a ip prakticky totožné. Pak se učit nástroj "ip" je fakt jen kvůli tomu, "že to někdo řekl", protože skutečná potřeba v mém případě nemusí existovat. Pokud chci na Linuxu dělat větší síťování, pak už "ip" potřebuju a naučím se ho rád.

Osobně mi ip nedělá problém a považuju ho za srozumitelný a dobře ovladatelný nástroj. FreeBSD ifconfig taky, ale Linuxový ifconfig rád nemám.

Na servery mám radši FreeBSD, právě kvůli tomu, že se tam nemění tolik mechanismů, jako v Linuxu, které v mém případě vůbec nic nepřinášejí. FreeBSD také doporučuji.

Tento problém neřeší jen Linux, ale třeba i Windows. PowerShell je taky nový a opravdu dobře navržený nástroj, příkazy dávají smysl a dá se s nimi nastavit víc. Přesto se mu setrvačností obrovská část adminů vyhýbá. To je ten samý případ, jen v bledě modrém.

Existuje jiný systém pro komplexní, deklarativní, nezávislé nastavení sítě než Netplan?

Proč? Protože prostě není důvod se učit něco jiného. Stačí na většinu věcí. Reálný přínos je nulový. Navíc mi přijde, že ifconfig má jednodušší rozhraní, ale to může být jen můj subjektivní dojem. Mentální aktivitu člověk raději vynaloží na skutečnou práci.

Už je to nějaký čas, co jsem SFTP použil místo SCP, ale pamatuji si, že SFTP bylo řádově několikrát pomalejší než SCP.

Jinak, občas, pokud mi je jedno, že někdo poslouchá a integritu si ověřím tak používám na přenosy "nc" v kombinaci s "tar" (Asi by to šlo zabalit i do stunnelu, ale ten není zas tak běžný. Nebo použít port forward a celé to zabalit do aktuální ssh sessiony,....ale počkat, není to přesně to co dělá SFTP?)

Ja to uplne nepochopil, co je na scp vlastne spatne? Ty 2 bezpecnostni diry? Hmmm, to je sice mrzute, ale co zaruci, ze jide bezpecnostni diry nebudou? Co vlastne na tom protokolu konkretne vadi? Jak to chapu, tak nebezpecny neni protokol, ale chyby v scp, ktere vsak jiz byly opravene, tak o co jde?

"Například váš korporátní server má kvůli ‚bezpečnosti‘ vypnutý subsystém sftp v SSH," dodává Jelen.

ehm, ehm........

V korporátním systému se to děje tak, že přenosy se dějí jen pomocí sFTP. To je nastaveno na chroot, pro konkrétní skupinu aby se pomocí klasického SSH nebo SCP ani nedalo přihlásit. Dále tyto účty pro komunikaci používají samozřejmě SSH klíče, samostatné VLAN např. atd.

Takže ano, zatímco jedni si nevýhody velmi dobře uvědomují a snaží se s tím něco udělat v rámci obecně rozšířeného OpenSSH, ale kvůli zpětné kompatibilitě a podobně to není jednoduchý úkol, tak druzí se rozhodnou znovu objevit kolo. Zatím jen ve formě maskování sftp za příkaz scp, ale to si mohou uživatelé udělat i nyní pomocí skriptů.

Proč to jen připomíná již zde zmiňovanou situaci ifconfig vs ip nebo netstat vs ss a další?

Na scp vzpomínám s láskou vždy, když potřebuji něco nakopírovat do OneDrive cloudu od Microsoftu. Kopírování přes běžné příkazy nebo klienty tam vždy po přenosu několika tisíc souborů selže. Jediný příkaz, který dokázal přenést několik GB malých souborů, je Rclone.

Možná by byla cesta skrze https://github.com/MarcelMeurer/PowerShellGallery-OneDrive

Ale neznám, jen vím, že to existuje.

Obecně už i MS pochopil i třeba na Azure, že GUI je jen pro jednorázové a lehké úkoly a jinak se má používat AZ shell nebo PowerShell :-D

No nevím, já jsem si tak nějak zvykl, co do rychlosti, na příkaz sshfs a řešit všechno proti /mnt/remote. Jak proti USB disku.

Konfiguráky na routeru atd. si touhle fintou s SSHFS držím v GITu, mám extra repozitář, ve kterým skriptem mountnu adresáře s konfigem zařízení do adresářů v něm a hotovo. Vůbec nevadí, že třeba na routeru nabo APčku GIT není.

Ono sftp je hodně nepraktický, scp omezený a rsync na pár souborů je s kanónem na vrabce se vším tím komprimováním, skenováním cíle,...

Nedavno tu pri chybe v RDP niekto tvrdil, ze s ssl/scp by sa nieco take nikdy nestalo :D

Minuly tyden jsem pravdepodobne poprve v zivote pouzil ip misto ifconfig/route a podobnych ve scriptu, protoze se mi libilo umet zjistit adresu lokalniho interface v zavislosti na destination adrese. To jsem si dal. Krasne jsem to odladil na ubuntu a ono to pak na synology nejelo, protoze ten blbej ip na synology ma jinak zformatovany vystup nez ten jeste blbejsi ip na ubuntu. Kdyz uz vymysleli krasnou novou utilitu, taky ji mohli standardizovat!
Pokud byste nekdo potrebovali neco podobneho, tak command
ip route get $ip | head -1 | sed "s/^.*src.\\([0-9.]*\\).*$/\\1/"
vrati adresu lokalniho interface v zavislosti na target ip. Tohle je uz upravena verze, ktera chodi jak na synology, tak na ubuntu. Jinde jsem to nezkousel.

ip -j route get $ip | jq -r '.[0].prefsrc'

Představte si, že oni ji standardizovali. A ne hloupě standardizací výpisu určeného pro člověka, jako to mají jiné nejmenované utility. Udělali to výstupem do strojově zpracovatelného formátu – JSON.

Dovolím si odcitovat něco z výborné knihy. Jmenuje se The Linux command line https://nostarch.com/tlcl2

During the 1980s, Unix became a very popular commercial operating system,
but by 1988, the Unix world was in turmoil. Many computer manufacturers had
licensed the Unix source code from its creators AT&T, and were supplying various
versions of the operating system with their systems. However, in their efforts
to create product differentiation, each manufacturer added proprietary changes
and extensions. This started to limit the compatibility of the software. As always
with proprietary vendors, each was trying to play a winning game of “lock-in” with
their customers. This dark time in the history of Unix is known today as the
Balkanization.