Sziasztok!
Seafile 7.x vagy újabb telepítésében kérném nálam tapasztaltabbak segítségét. Jelenleg egy 6-os verzió fut gond nélkül, de mivel ebben még nincs lehetőség a fájlok keresésére, így gondoltam feltennék egy 7.x vagy újabb verziót.
Sajnos azonban 7-től felfelé már python 3 kellene (plusz a bánat tudja még milyen csomagok), aminek telepítése egy 18.04-es ubuntu szerver környezetbe számomra nem annyira triviális.
Sok témát és a Seafile saját oldalain található Howto-kat is átolvastam már, de nem jártam sikerrel telepítés terén :-(
Az sem segít, hogy a 6-os változatot frissítem, mert nem magával a Seafile-lal van probléma, hanem a szoftveres háttérrel (illetve annak hiányával)
A seahub indítása során ebbe a hibalistába futok bele:
Traceback (most recent call last):
File "/media/tesztcloud/seafile-server-7.1.5/seahub/manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/media/tesztcloud/seafile-server-7.1.5/seahub/thirdpart/django/core/management/__init__.py", line 364, in execute_from_command_line
utility.execute()
File "/media/tesztcloud/seafile-server-7.1.5/seahub/thirdpart/django/core/management/__init__.py", line 338, in execute
django.setup()
File "/media/tesztcloud/seafile-server-7.1.5/seahub/thirdpart/django/__init__.py", line 27, in setup
apps.populate(settings.INSTALLED_APPS)
File "/media/tesztcloud/seafile-server-7.1.5/seahub/thirdpart/django/apps/registry.py", line 85, in populate
app_config = AppConfig.create(entry)
File "/media/tesztcloud/seafile-server-7.1.5/seahub/thirdpart/django/apps/config.py", line 94, in create
module = import_module(entry)
File "/usr/lib/python3.6/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 994, in _gcd_import
File "<frozen importlib._bootstrap>", line 971, in _find_and_load
File "<frozen importlib._bootstrap>", line 953, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'captcha'
Sokféleképpen próbáltam már megoldást találni a hiba megszüntetésére, de ehhez sajnos nincs tapasztalatom.
Ha valakinek sikerült már 18.04-es környezetbe beüzemelni egy 7, vagy újabb seafile-t, és megosztaná velem az ezzel kapcsolatos tudást,... ...hát azt nagyon megköszönném!
Lehetséges ezt egyáltalán megcsinálni, vagy engedjem el és maradjak a jól működő 6-os vonalnál?
Hozzászólások
Rakd fel Dockerrel: https://manual.seafile.com/docker/deploy_seafile_with_docker/
A szerver nem docker-ben fut, így tartok tőle, hogy ez nem fog menni sajnos.
A szerveren (Ubi 18.04) futtasd a Seafilet dockerben. Pont az ilyesmire találták ki, nem kell bajlódnod a függőségekkel sem. A két dolognak semmi köze egymáshoz, de mindegy, egy tipp volt, percek alatt meglenne.
Oké, nem vetettem el az ötletet, csak pluszban még a docker-ből is ki kellene kupálnom magam, amihez most igazán nincs ingerenciám... ...ettől függetlenül köszönöm az ötletet!
Még várnék, hátha valaki sikeresen megoldotta már ezt a python (és egyéb csomagok) problémát...
A "más" megoldás, hogy nem csomagból próbálsz frissebb pythont varázsolni. Good luck, szerintem nagyságrendileg több szopás kézzel egy frissebb pythont felrakni, mint fellőni docker konténerben a seafile-t.
Vagy a seafile-t rávenni, hogy "python" helyett "python3"-at használjon... (A symlink átvakarást nem javaslom...)
Nem vagyok meggyőződve, hogy az a régi 3-as Python elég jó neki (csomagból valami fosrégi Python 3 kerül fel emlékeim szerint ezekre a régi oprendszerekre, bár lehet, hogy a CentOS 3.5-ösével keverem, na az full használhatatlan).
Nálam CentOS-ban (CentOS Stream release 8) 3.6.8 a python3, a python2 2.7.18, ugyanez Ubuntu 18.04.6 esetében 3.6.9 illetve 2.7.17, Ubuntu 20.04.5 alatt 3.8.10 van alapból, python2-ből 2.7.17 lenne telepíthető.
A https://manual.seafile.com/upgrade/upgrade_notes_for_7.1.x/ azt mondja, hogy dependál a python3-ra, és 3.6 meg 3.7 is jó neki, és hogy 6.x -> 7.0.x -> 7.1 az upgrade path, direktben 6.x -> 7.1 nem támogatott.
Na, közben megvan: a 16.04-es Ubuntun ragadt 3.5-ön a system python3 csomag. Emiatt oda nem bírtam sehogy sem felrakni a gyári seafile kliens csomagokat sem.
És értem, hogy 2022-ben a 16.04-es Ubuntu már obsolete, de 2020 decemberében még nem volt az, és már akkor sem volt frisebb python csomagban.
Az nagyon szép... A 3.5-ös Python 2020.09. hóban volt EOL, gondolom a canonical döntése volt, hogy ESM-ben még hajlandó támogatást (sec.fix) adni hozzá, de a 3.6 és újabb verziókat már nem pakolta be a normál supprt szempontjából EOL-os rendszerbe. (Ha jól látom, az ESM-es 16.04-ben is csak 3.5-ös Pythont kap az ügyfél).
Szerintem nemes egyszerűséggel az a taktika, hogy nem csinálnak python verzióváltást. Azaz ami verzió kijön arra az Ubuntura, az marad a végéig. És akkor problem solved, akinek nem tetszik, az oldja meg, ahogy akarja, rakjon fel kézzel valamit, vagy upgradelje az OS-t.
BTW ha nyomsz arra a 3.5-re pippel egy frissítést, akkor a pip szemrebbenés nélkül felupgradeli saját magát egy olyan verzióra, ami már fizikailag nem képes futni 3.5-ön (valami ordas nagy exceptiont nyom), és utána lehet kézzel levakarni az egészet.
Na ezért mennek ezek a szarok nálam dockerben.
Nálam meg ami megy repóból, az van, ami meg nem megy repóból, az nem választható komponens, akármennyire is kapálóznak a kódtaknyolók.
És ami repóból frissül, az nagyon pici valséggel fog olyan elborulást csinálni, mint amit te emlegetsz.
system python-t ubuntun nem piszkaljuk, mert torik :D
ha valakinek kell frissebb python/ python package valamibol, akkor --user kapcsoloval felteszi maganak, vagy pyenv-vel telepit sajat pythont.
Az update-alternatives lesz a barátja.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
vagy a python3-is-python vagy hogy a pékbe' hívják csomag (csak a python symlinket cseréli le)... Hogy eltör-e valamit, ami eddig ment az ócska pájtonnal, azt csak úgy fogja megtudni, ha kipróbálja. Bár a csillió+1 nem csomagból felkalapált kiegészítő nem kecsegtet sok jóval...
"ModuleNotFoundError: No module named 'captcha'" és "Sokféleképpen próbáltam már megoldást találni a hiba megszüntetésére"
Ez az jelenti, hogy felraktad a captcha modult?
Ha jól emlékszem megkíséreltem azt is feltenni, de annak is volt valami függősége. Az a helyzet, hogy nem voltam elég bátor ahhoz, hogy a sok-sok egyéb más oldalon lévő javaslat alapján mindenféle random csomagot telepítsek, mert tartottam tőle, hogy előbb-utóbb eltörik valami, aztán meg majd csak pislogok.
Ezért fordultam hozzátok, lehetőség szerint kész, kipróbált megoldásért.
Majd felteszek virtuális gépre egy szervert, aztán azon kísérletezek (tudom, ezzel kellett volna kezdeni). Csak hát kezdetben nem tűnt bonyolultnak a probléma, így nem ezzel kezdtem.
Pedig az install section szerint mennie kellene.
https://manual.seafile.com/deploy_pro/download_and_setup_seafile_profes…
Majdnem mondtam, hogy virtualenv, esetleg pyenvvel teljesen custom pythont feltenni, de most latom, hogy itt minden is kell (python, java, stb), szoval nem tudom mennyire hekkelheto a python resze.
Sajnos a telepítés végén ez a hibaüzenet jön:
Command "/usr/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-7alltilg/pylibmc/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-jye5n79u-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-7alltilg/pylibmc/
A "python compile failed error code 1"-re azért van találat a gugliban...
...és valóban. Köszönöm!
pip3 install
Nekem már sikerült szétbaszni OS csomagként felrakott python + modulok kombóját a pip paranccsal felrakott/megupgradelt modulok útján. Az én tapasztalataim szerint ez a kettő telepítési módszer nem kompatibilis egymással, mivel a pip nem ismeri az OS csomagokat meg azok dependenciakezelését, és simán megpróbálja megfrissíteni a csomagból felrakott modul fájljait úgy, hogy közben az OS meg azt hiszi, hogy az eredeti csomag van még fent.
Hogyúgyvan... Volt, hogy egy 16.04-et frissíteni sem sikerült - pont ilyen pájtonos gányolás miatt, mert a do-release-upgrade szépen beledöglött egy méretes pájtonos stacktrace kíséretében...
yup, system pythonhoz nem jo pippel nyulni foleg ubuntun, mert ott aztan van kavar (dist-packages, es egyeb csodalatos dolgok, legalabb 3-4 helyen lehet ugyanaz a package telepitve). pyenv, vagy `pip install --user`
Tegyed fel flatpak-ból, úgy tartalmazza a saját függőségeit (de csak a GUI kliens fog menni, a CLI része szerintem nem). Általánosságban viszont minden szoftvernek gondja lesz, ha nincs Python 3, szenvedni fogsz mindennel. Épp ezért szoktam írni, hogy ezeknek az 5-10 évig támogatott LTS disztróknak nincs értelme, túlzottan elavulnak a csomagok már alig néhány év múltán, dinoszauruszok korabeli rendszerre alapozni agyrém. Semmi új verzió vagy új feature nem fog rajta menni.
Az a 18.04 már úgy is csak fél évig támogatott, nyergelj át a 22.04-re. Azon ott lesz a viszonylag frissebb Python 3.10.4.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Nem a kliens részével, hanem a seafile-server telepítésével van probléma. Tegnap este megtaláltam a régi jegyzeteim között az ide vonatkozó részt, de még csak átnéztem, majd ma kipróbálom.
Viszont Fisher javaslata alapján felraktam csak a captcha modult. Javult a helyzet, mert a seahub is már elindul. A seafile még leáll "internal server error" hibával, de ez már valószínűleg csak beállítás kérdése... ...majd kipuskázom a működő 6-osból a beállításokat, aztán próba.
A 18.04 egyelőre marad. Amire kell, azt még gond nélkül tudja. A seafile-nak meg nem ezen kellene lenni, de sajnos nincs más lehetőségem máshol futtatni, úgyhogy ha felmegy, akkor lesz 7 (vagy 9), ha nem akkor meg marad a 6.
A rendszer meg majd egyszer kap egy frissítést, de az biztos, hogy nem mostanában lesz.
Ezekkel az univerzális konténerizált formátumokkal csak a GUI appok kompatibilisek. A CLI/demon típusú szoftverek nem. Akkor amíg nem váltasz LTS verziót, addig felteszel egy 22.04-et (szervertelepítésben lehetőleg, GUI nélkül) virtuális gépben, vagy konténerben, és nyomod arról a szervert.
Azzal nem értek egyet, hogy amire kell, azt gond nélkül tudja a 18.04. Pont erről szól a topik, hogy nem tudja. Az a baj, hogy ezt nem szokták nekem elhinni, hogy a Linux nem Windows, ahol 10 évig elvagy egy főkiadással, mert bináris visszafelé komptibilitás van. A Linux világa nagyon gyorsan változik, csak úgy röpködnek az újdonságok, systemd, pipewire, wayland, stb., python2 helyett 3, új Perl, új PHP főverzió, legújabb Gtk és Qt verziók, itt nincs idő hátra dőlni, meg lustulni, nem lehet lemaradni. Ez az ára annak sajnos, hogy ingyenes.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
A mondadód lényegével maximálisan egyet értek, de
csak úgy röpködnek az újdonságok ... python2 helyett 3
azért a python 2 már 5 évvel ezelőtt is obsolete volt. Szóval ez kicsit olyan, mint a csigás viccben, hogy "és akkor hopp, kinőtt előttem egy gomba"...
"A 18.04 egyelőre marad. Amire kell, azt még gond nélkül tudja." - Kivéve a friss seafile futtatását, amit ugyebár egy 20.04-es (3.8-as python-nal) simán megugrana... Én nem babusgatnám a lassan EOL-ba hajló 18.04-et, hanem felhúznám 20.04-re, aztán azzal el lennék még jó sokáig. A snap/docker/flatpack és hasonló megoldásokat nem igazán javaslom a te esetedben, mert 9x%, hogyha működik, akkor egy do-release-upgrade után is marad az, ami most felment "egybe csomagolva", miközben a körülötte lévő OS-ben meg normál repóból frissül(het)nek a cuccok.
Még azt is elfogadnám egyébként, hogy oké, lemond erről az új verzióról. De minek korlátozná magát le, ha egyszer pont ez a lényege a Linuxnak, hogy ne legyen kötöttség, mint Windowsnál, Mac-nél, ahol egy gigamulti dönti el egy lezárt rendszeren, hogy mi támogatott, mit és hogyan lehet futtatni. Linuxon ugyebár minden csak a useren, adminon múlik, lehet dolgoznia kell érte/vele, de elérhető bármi, amit akar, feltéve, hogy nem lusta az alapvető munkát beletenni. Onnantól, hogy egy linuxos rendszert telerakunk ilyen version-lock-in-nel, onnantól az egésznek az értelme le lett húzva a klotyón, annyi erővel Windowst is lehetne használni.
A másik, hogy egy elavult rendszerbe nem érdemes munkát feccölni, csak azért, hogy állandóan életet leheljünk bele. hajbazer is ezt nem érti az XP-jével, hogy oké, most ő a fasza antikonzumer messiás, hogy csak azért is használja tovább, de egy csomó munkát bele kell tennie, sok dolgot körbehekkelnie, keresgetnie, kínai böngészőzni, egyéb trükkök. Mindez a fetrengés azért, hogy egy elavult rendszert feleslegesen életben tartson, olyat, aminek nincs jövője. Ennyi erővel ugyanazt a munkát beletette volna valami modern linuxos ökoszisztémába, az is pain in the ass lett volna adott esetben, de most lenne egy olyan rendszere, tudása, aminek van is jövője, de szintén nem konzumer birka rendszer, nem kell alá új gépet, stb. venni.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
a "python" az a 2.7-es az Ubuntu 18.04-en, a 3-as verziót python3 néven (3.6) lehet elérni, úgyhogy lehet, hogy némi reszeléssel megoldható, hogy a problémás seafile ne a "default" python-t (2.7), hanem a python3-at használja, és maradhat a 18.04. Az, hogy egy app 2022-ben nem megy az eredetileg 2015, majd 2020-as EOL-os 2.7-es pythonnal, hát... Nem igazán lehet rajta csodálkozni...
Valószínű igazad van. A Python 3 első verziója 2008 decemberében jött ki, a majdnem egy évtizeddel rá megjelenő Ubuntuban ha nem lenne elérhető, az már önmagában gáz lenne. De nem csak a seafile-ról van szó, hanem lényegében ma már az összes aktuális kód, ami Python-ra épül és még gondozzák a kódbázisát, az min. 3.x-es Pythonra dependel. A 2-eset már tűzzel-vassal irtják, több disztró már a tárolójából is száműzte, hogy emberek ne ragadjanak rajta, nézzenek más alternatívák után. Pont azért, mert 7 éve deprecated, és 2 éve EOL-os is, és ha nem lépnének ez ellen, akkor a végtelenségig rajta ragadnának egyesek.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
En is a Dockert javasolnam, nalunk is ugy fut. Sokkal fajdalommentesebb az egesz, ha ugy futtatod.
Elviekben ha a /usr/bin/python symlinket átírod a python3-ra, akkor ugye a hármast fogja megtalálni - viszont ezzel elég sok ócskaságot el fogsz törni, úgyhogy ezt nem javaslom. (do-release-upgrade döglött már meg python mókolás miatt...)
Ha a motyót rá tudod venni, hogy ne a "python"-t, hanem a "python3"-at keresse, akkor nyert ügyed van szerintem...
Nem kell docker, Virtualenv van Pythonban, használható 18.04-en a Python 3.6-al.
https://pythonbasics.org/virtualenv/
Aztán a venv-be azt raksz fel pip-el, amit akarsz, nem fog semmit összekavarni az OS-en. Root jog se kell hozzá.
vagy kib...csizza a 18.04-es buguntut a default 2.7-es pájtonjával együtt. :-P A venv-es móka addig jó, amíg nem dönt úgy, hogy na, akkor 20.04/22.04, és lehet a venv-es motyót kihajítani, és a "rendes", az OS-sel érkező python-ba belerámolni mindent _is_ amit a venv-be bepakolt.
Ennyi erővel dockert se használjon. És ha már választani kell, inkább a venv, mint a docker.
A venv-es móka egy fapados, törékeny "hack" reprodukálhatóság szempontjából egy konténerhez képest. Ettól függetlenül semmi nem akadályozza meg a júzert abban, hogy a későbbi OS-eken se a system pythont használja, hanem oldja meg máshogy, pl. venv vagy konténer alapokon (sőt, bátran nevezhetjük best practice-nek, hogy nem használjuk a system pythont, akkor se, ha most pont megfelelő verzió).
Esetleg (ami neked felesleges ne tedd fel, nálam ez így van lementve):
cd /srv
apt install -y net-tools mc openvpn borgbackup mariadb-common mariadb-server python3 python3-setuptools python3-pip libmariadb-dev memcached libmemcached-dev mariadb-server wget
pip3 install --timeout=3600 django==3.2.* Pillow pylibmc captcha jinja2 sqlalchemy==1.4.3 django-pylibmc django-simple-captcha python3-ldap mysqlclient pycryptodome==3.12.0 cffi==1.14.0
wget https://s3.eu-central-1.amazonaws.com/download.seadrive.org/seafile-server_9.0.4_x86-64.tar.gz
tar xvzf seafile-server_9.0.4_x86-64.tar.gz
cd seafile-server-9.0.4/
mariadb-secure-installation
./setup-seafile-mysql.sh
Kitöltjük, értelemszerűen
./seafile.sh start
./seahub.sh start
első indításkor megadjuk az adatokat
sed -i 's/127\.0\.0\.1/0\.0\.0\.0/g' ../conf/gunicorn.conf.py
./seafile.sh restart
./seahub.sh restart
nano /etc/systemd/system/seafile.service
nano /etc/systemd/system/seahub.service
systemctl enable seafile
systemctl enable seahub
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
Köszönöm!
A docker image mellett szólóan:
- sose láttam még a seafile-t, de van egy (pár) kész docker környezetem
- kb. 3 perc alatt megtaláltam a "gyári" seafile csomagot és fel is ment
- kettő darab könyvtárat kellett módosítani a docker-compose fileban hogy a nekem megfelelő helyre pakoljon
- bár teljesen érdektelen de ubuntu 20.04 alatt python 3.8.10-el fut a seafile
A 18-as ubuntura nagyjából 10 perc alatt felrakható a docker és a docker-compose is alapszinten.
Szerintem messze kevesebb kínlódás mint amit a pythonnal venv-el be lehet kapni.
All in all, rendszergazdának _nagyon_ érdemes megtanulnia dockerezni. Hogy mást ne mondjak ez a belépő szintű tudás a Kuberneteshez - ami most a csapból is folyik.
Gábriel Ákos
Engem az érdekel nagyon, hogy ha van egy szerver, amin annyira nem fontos dolgok futnak, hogy lehet rajta ilyen főverzió upgrade kísérletet folytatni, akkor milyen racionális magyarázat van arra, hogy nem frissítjük az OS-t 18.04-ről 20.04-re legalább, de méginkább 22.04-re?
Látatlanban biztos vagyok benne, hogy az eddigi Seafile kínlódásra sokkal több idő elment már, mint amennyiből 22.04-en lenne a rendszer _és_ futna rajta a frissített Seafile.
Zimbra frissítésre kértek fel egyszer, ami rettentően el volt maradva az aktuálistól. Ubuntu 14.04-en futott. Újratelepítés is szóba jött, de attól valamiért fázott mindenki, aki Zimbrában jártas. Így lett egy OS 16.04 upgrade, majd ott egy Zimba upgrade kicsit újabbra, mert az éppen futó nagyon régi már nem volt elérhető 18.04-en, majd OS 18.04-re, azon Zimbra a legfrissebbre, és kész. 20.04 már volt éppen, de a Zimbra még nem volt kint rá csomagban, így maradt a 18.04. Nagyjából 3-4 óra volt az egész úgy, hogy még fizikai HDD-ről csináltunk lemezkép mentést a művelet elején...
Én nagyon szeretem az LTS verziókat, mert jó hosszan lehet húzni a frissítést (ahol ugyan azt csinálja a gép éveken át, semmi plusz igény nem jön), nem tudok "kifutni" az időablakból. De azért frissítem az összes rendszert valamilyen ütemezés szerint, hogy ne fussak bele ilyen pofonba, ha hozzá kell nyúlni évek múltán bármiért.