David Malcolm se na blogu vývojářů Red Hatu rozepsal o vybraných novinkách v GCC 16, jež by mělo vyjít v nejbližších dnech. Vypíchnuta jsou vylepšení čitelnosti chybových zpráv v C++, aktualizovaný SARIF (Static Analysis Results Interchange Format) výstup a nová volba experimental-html v HTML výstupu.
Byla vydána verze R14.1.6 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Jon Seager z Canonicalu včera na Ubuntu Community Hubu popsal budoucnost AI v Ubuntu. Dnes upřesnil: AI nástroje budou k dispozici jako Snap balíčky, vždy je může uživatel odinstalovat. Ve výchozím nastavení budou všechny AI nástroje používat lokální AI modely.
Nový ovladač Steam Controller jde do prodeje 4. května. Cena je 99 eur.
Greg Kroah-Hartman začal používat AI asistenta pojmenovaného gkh_clanker_t1000. V commitech se objevuje "Assisted-by: gkh_clanker_t1000". Na social.kernel.org publikoval jeho fotografii. Jedná se o Framework Desktop s AMD Ryzen AI Max a lokální LLM.
Ubuntu 26.10 bude Stonking Stingray (úžasný rejnok).
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.3.0. S experimentální podporou FLTK 1.4. S příkazem dilloc pro ovládání prohlížeče z příkazové řádky. Vývoj prohlížeče se přesunul z GitHubu na vlastní doménu dillo-browser.org (Git).
Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Vývojáři v přehledu vypíchli vylepšenou instalaci, podporu senzoru okolního světla, úsporu energie, opravy Bluetooth nebo zlepšení audia. Vývoj lze podpořit na Open Collective a GitHub Sponsors.
raylib (Wikipedie), tj. multiplatformní open-source knihovna pro vývoj grafických aplikací a her, byla vydána ve verzi 6.0.
Nové verze AI modelů. Společnost OpenAI představila GPT‑5.5. Společnost DeepSeek představila DeepSeek V4.
Nedávno jsem narazil na suPHP, je to výborná věc k zabezpečení servru. Jeho konfigurace není nijak složitá a nezaregistroval jsem ani žádné významné zpomalení.
Představme si, že máme webhostingový server a na něm máme spuštěný Apache pod UID 1, a tři klienty s UID 2,3,4.
Každý z klientů má svůj vlastní prostor, kde má soubory s vlastním UID. Soubory nahrané z FTP se ukládají na server s tímhle UID. Problém, ale nastává, pokud vytvoříme nějaký soubor z PHP. Tenhle soubor se vytvoří pod UID Apache (UID 1) - mimo jiné musí mít do tohoto místa Apache povolení k zápisu.
Tzn. že se soboru s UID 1 se můžou vyskytovat v prostorech všech klientů, kteří je můžou sami sobě měnit. Tohle se dá částečně vyřešit použitím starší direktivy v php safe_mode nebo použít open_basedir. Tohle ale akorát zabrání aby si klienti mezi sebou soubory měnili, ale soubory jsou vytvářeny pořád pod UID Apache. Což nám komplikuje například použití kvót (které jsou vázané na UID nebo GID).
suPHP je modul do Apache, který nahradí standartní mod_php. Skripty poté vytváří soubory pod svojím UID, nikoli pod UID Apache.
Instaloval jsem suPHP na Ubuntu Server. Postup na Debianu bude velice podobný, možná úplně stejný.
martin@tuxnak:~$ apt-cache search suphp libapache2-mod-suphp - Apache2 module to run php scripts with the owner permissionsNainstalujeme balíček
martin@tuxnak:~$ apt-get install libapache2-mod-suphpPoté musíme aktivovat tenhle modul v konfiguráku Apache, přidáme tyto řádky
LoadModule suphp_module /usr/lib/apache2/modules/mod_suphp.so
<IfModule mod_suphp.c>
AddHandler x-httpd-php .php .php3 .php4 .php5 .phtml
suPHP_AddHandler x-httpd-php
suPHP_Engine on
suPHP_ConfigPath /etc/suphp/suphp.conf
</IfModule>
V Ubuntu stačí spustit
martin@tuxnak:~$ ln -s /etc/apache2/mods-available/suphp.* /etc/apache2/mods-enbaled/Poté musíme zrušit v Apache mod_php. Zakomentujeme v konfiguráku tyhle řádky:
LoadModule php5_module /usr/lib/apache2/modules/libphp5.soV Ubuntu spustíme
martin@tuxnak:~$ rm /etc/apache2/mods-enabled/php5.*
Nachází se se v /etc/suphp/suphp.conf
Defaultně je nastavený dost konzervativně. Projdeme si všechny důležité konfigurační direktivy.
[global] logfile=/var/log/suphp/suphp.log Cesta k logu loglevel=info Podrobnost logování webserver_user=www-data Nastavíme uživatele pod kterým běží apache docroot=/home Nastavíme adresář, ze kterého budou spouštěny skripty allow_file_group_writeable=false Zakáže aby skripty byli přepisovatelné skupinou. allow_file_others_writeable=false Zakáže aby byly skripty přepisovatelné, těmi kteří nejsou ani vlastníci a a ani nejsou ve skupině allow_directory_group_writeable=false To samé s adresáři allow_directory_others_writeable=false check_vhost_docroot=true Kontroluje jestli skript není mimo documentroot umask=0077 maska pro soubory vytvořené z php min_uid=100 Skripty s menším UID server nespustí a vyhodí chybu min_gid=100 To samé s GID [handlers] x-httpd-php=php:/usr/bin/php-cgi musíme nastavit handler - cestu k php interpretu
Je to první návod, který jsem zveřejnil. Možná někomu pomůže, ale nerad bych aby někoho popletl ještě víc, pokud bude někde chyba nebo vás napadá lepší řešení, napište prosím do komentářů.
Tiskni
Sdílej:
nemusi pak ale apache bezet pod rootem ?IMHO nie.
root 15121 16.0 7.5 31628 24236 ? Ss 14:28 0:00 /usr/sbin/apache2 -k start www-data 15124 0.0 7.3 31628 23712 ? S 14:28 0:00 /usr/sbin/apache2 -k start www-data 15125 0.0 7.3 31628 23712 ? S 14:28 0:00 /usr/sbin/apache2 -k start www-data 15126 0.0 7.3 31628 23712 ? S 14:28 0:00 /usr/sbin/apache2 -k start www-data 15127 0.0 7.3 31628 23712 ? S 14:28 0:00 /usr/sbin/apache2 -k start www-data 15128 0.0 7.3 31628 23712 ? S 14:28 0:00 /usr/sbin/apache2 -k start
Ano. Lighttpd. Pro každé stránky spustíte zvlášť démona v chrootu a poté jednoho na portu 80, který přes mod_proxy kontaktuje ty ostatní např. podle domény. Ale je to docela náročné na správu (v každém chrootu vlastní php + závislosti, ale vejdete se do 10 MB na "vhost").
Není to můj nápad, ale nápad "cx".
Už jsem to tu řešil, můžeš použít FastCGi se SuExecem a wrappery (to ti umožní i provozovat vedle sebe PHP4 a PHP5, i když PHP4 už patří do koše, spíš je to zajímavé na testování CVS PHP6), nebo, a to je podstatně jednodušší, mod_ruid. Vygoogli si to, jenom bacha na mpm-worker, jak popisuju tady, už se to delší dobu chystám postnout sem, ale nějak jsem se k tomu nedostal, zajímaly by mě totiž i vaše komentáře, snad brzo ...
Snad to pomůže vyřešit daný problém, jinak podle vlastních testů je suPHP asi 15x pomalejší než mod_php s mpm-worker a asi 10x pomalejší než mod_php s mpm-prefork nebo s řešením FastCGI/SuExec, takže bych se ho na mass hosting určitě dost obával :/