Ja jsem dlouhodoby uzivatel Linuxu (od roku 97) a dnes po nem uz jen chci, aby dobre fungoval, nemam cas se v nem stourat jako zamlada. Konzervativni pristup ubuntu mi vyhovuje. Verze 14.04 me zklamala, je nestabilni, ma problemy s ftp a dokonce mi cas od casu zatuhne, takze se na 16.04 tesim a doufam, ze bude bez problemu.
Není to blábol. Ubuntu 14.04 opravdu trpí dlouhodobě problémem s připojením ftp/sftp z Nautilusu. Já to používám dost intenzivně a tak obden se mi stane, že spojení zatuhne, od serveru se nedá odpojit a je třeba ručně pozabíjet příslušné procesy a někdy dokonce i restartovat Nautilus.
Pokud bude tohle v 16.04 vyřešeno, budu nejšťastnější člověk na světě.
"Tenhle bug je i v mintu"
Vzhledem k tomu, že Mint používá balíčky Ubuntu, je to docela logické. Otázka je, jestli je ten problém i v upstreamové verzi. Upstreamové bugzilly jsou plné uzavřených bugů s vyjádřením "U nás dávno opraveno, dokopejte správce balíčku ve vaší distribuci, ať tam tu opravu aplikuje".
No docela by mě zajímalo vaše řešení, jak relativně pohodlně nahrát/spravovat/aktualizovat web na hostingový server s možností např. úpravy oprávnění na adresářích/souborech... Přesně k tomu byl FTP protokol navržen a to, že to už bylo dávno nic nemění na tom, že je stále velmi dobře použitelný, tudíž jeho existence má své opodstatnění. Stejně jako SMTP, IMAP atd.
Aby nedošlo k omylu, samozřejmě je řeč o přístupu na úrovni tvůrce/správce webu/webové aplikace, ne o správě obsahu.
Samozrejme, ze git. Jak treba pres to tvoje FTP poznas, ze nemas nejaky hack v nejakym souboru? Jak pres ftp "posles" jednoduse delete(jednoduse = tak abys na to nemusel myslet)? Jak resis kdyz na tom pracuje > 1 clovek? Jak resis (i kdyz tam mas 1 jedineho vyvojare) vyvoj vice features/bugfixes najednou?
Tazek za me: ne, FTP uz davno neni vhodne vubec na nic.
GIT se samozřejmě dá použít pro deploy aplikace na server a má na to přímo hook: "post-receive" a použije se proměná "git --work-tree". Samozřejmě FTP má ne 90 a 99% hostingů a zároveň nenabízí SFTP. Ale to nikdo neřeší. Ještě jsem nezažil firmu, kterou by to zajímalo. Naopak, ještě si hesla posílají mailem. Git deploy, jak jsme používali, je ideální na stejném stroji, ale dá se udělat i workaround přes FTP nebo SSH. Jestli si vzpomínám, používali jsme GIT deploy přes SSH.
FTP = file transfer protocol. To myslím hovoří za vše. Zcela jistě existují situace, kdy vyhovovat nemusí. Nicméně to, k čemu byl navržen a je používán (přenos souborů) dělá dobře a spolehlivě.
Nebo opravdu v situaci, kdy potřebujete nahrát na server jeden soubor nebo pár fotek, použijete git?
Nebo v situaci, kdy tam jednorázově nahrajete celý web (hotový, nemluvím o vývoji)? Nesmysl.
Ale jo, mailuje to na výbornou na milionech mailserverů. Nemá to totiž žádný problém s dynamickými porty, narozdíl od zoufalého FTP protokolu, který se stává ještě zoufalejším, pokud člověk použije k přihlášení a přenosu dat šifrovanou komunikaci, protože do toho firewall už nevidí vůbec a nenadělá s tím vůbec nic.
Tak samozřejmě všichni víme co je FTP. Osobně GIT deploy nepoužívám, používám takové "custom" scripty na deply a přes FTP/SFTP podle toho, co daný klient má/požaduje.
Pokud ale máte třeba managed server s GITem, pracujete v gitu a deploy máte nastaven přes SSH (třeba pokud nemáte možnost SFTP) a jenom si vyplníte cestu k webrootu, tak proč to nedělat deploy přes GIT?
"Nebo opravdu v situaci, kdy potřebujete nahrát na server jeden soubor nebo pár fotek, použijete git?"
To ale nikdo neřekl v tom vláknu pokud vím. To je nějaká vaše konstrukce, kterou jste sem vsunul.
"Nebo v situaci, kdy tam jednorázově nahrajete celý web (hotový, nemluvím o vývoji)? Nesmysl."
No, jednorázově nahrajete web. Hmmm, ano i takové situace jsou. Taky si musíte nastavit FTP a nebo jako to máte na localu, tak dáte do scriptu GITu cestu k webrootu a každý push do mastera se nahraje.
No jasně, běžně se to dělá přes FTP/SFTP i já to tak momentálně dělám. Určitě. Ale co je obvyklý případ? Webhosting, FTP, totalcommander a nejaký Sublime 3. Ale taky jsou firmy, kde mají 1/2/3 ... managed or selfmanaged servery + GIT, projekty v GITU a bez push do mastera nic nerealesují, a tam je dobrý ten git deploy třeba. A nebo třeba ne. Je spousta možností jak to dělat nebo nedělat.
Ale vybral jste si jednu z možností deploye a ostatní šmahem zavrhl. Tak to ale nefunguje ....
Pane bože!!!
Můj původní příspěvek k chybě v 14.04, kdy jsou problémy se stabilitou FTP ve znění:
"Není to blábol. Ubuntu 14.04 opravdu trpí dlouhodobě problémem s připojením ftp/sftp z Nautilusu. Já to používám dost intenzivně a tak obden se mi stane, že spojení zatuhne, od serveru se nedá odpojit a je třeba ručně pozabíjet příslušné procesy a někdy dokonce i restartovat Nautilus.
Pokud bude tohle v 16.04 vyřešeno, budu nejšťastnější člověk na světě."
se dostal až k deployingu projektů přes git.
Pro boha svatého, dělejte si co potřebujete jak potřebujete, já si to budu dělat taky tak, jak to vyhovuje mi, ale pokračovat v téhle nesmyslné diskuzi, kdy jeden mluví o voze a druhý o koze, fakt pokračovat nehodlám.
Dobrou noc.
Aha, no tak to jsi asi zapomenul na tento:
"No docela by mě zajímalo vaše řešení, jak relativně pohodlně nahrát/spravovat/aktualizovat web na hostingový server s možností např. úpravy oprávnění na adresářích/souborech... Přesně k tomu byl FTP protokol navržen a to, že to už bylo dávno nic nemění na tom, že je stále velmi dobře použitelný, tudíž jeho existence má své opodstatnění. Stejně jako SMTP, IMAP atd."
A pak se oz val ještě někdo . . . . . . . . Ale promiň, jestli má tvé vlákno nějaké pravidla, možná by nebylo špatné kdyby jsi to napsal dopředu. Třeba: "Kdo odbočí od tématu, tak já už nehraju"
Tak jako kdo dnes nepoužívá VCS, ideálně GIT, je tak maximálně bastlič. Ale třeba místo CI nástrojů lze použít něco jako tohle, je to FTP script https://phpfashion.com/ftp-deployment-nahravejte-pres-ftp-chytre když člověk nemá plně automatizovaný deploy
- co presne myslis tim, ze nemam zadny ssh? (napada me jen git pres http, ale tak zase nejsem padlej na hlavu)
- co myslis uber kanalem?
- ne, ne, ne. nemam duvod to delat. a druhak nemam moznost to delat - proste ten klic ktery tam mam tak ma nastaveny na serveru readonly. nemam duvod nekam chodit do nastaveni a davat mu full a pak zpatky kdyz push z develop stroje znamena, ze mi to CI probubla az na produkci.