Премини към съдържанието
  • Добре дошли!

    Добре дошли в нашите форуми, пълни с полезна информация. Имате проблем с компютъра или телефона си? Публикувайте нова тема и ще намерите решение на всичките си проблеми. Общувайте свободно и открийте безброй нови приятели.

    Моля, регистрирайте се за да публикувате тема и да получите пълен достъп до всички функции.

     

petie1

Добри практики и Сигурност в Линукс

Препоръчан отговор


Нека в тази тема обсъждаме проблема със snap systemd и други подобни неддолюбвани неща за да не се пилее знанието по други теми

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Мен ми е интересно какъв е проблема със systemd - при условие, че се ползва реално от всички?
Преимуществате пред SystemV мисля, че всеки, който е писал сървиси ги знае. А и има доста неща, който нямат никаква алтернатива в класическата INIT система

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
преди 9 часа, borovaka написа:

Мен ми е интересно какъв е проблема със systemd - при условие, че се ползва реално от всички?
Преимуществате пред SystemV мисля, че всеки, който е писал сървиси ги знае. А и има доста неща, който нямат никаква алтернатива в класическата INIT система

Точно затова създадох темата

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
на 5.09.2019 г. в 11:45, borovaka написа:

Мен ми е интересно какъв е проблема със systemd - при условие, че се ползва реално от всички?
Преимуществате пред SystemV мисля, че всеки, който е писал сървиси ги знае. А и има доста неща, който нямат никаква алтернатива в класическата INIT система

Проблемът със systemd е начина му на налагане и хилядите омотани депендънсита, разпиляни файлове и кофти документация. Systemd е наложен по един много фашистки начин, който не оставя на потребителя избор. А това противоречи с философията на отворения код да има избор. Освен това авторите са едни много неприятни типове,които дори не обръщат внимание на репортнатите бъгове. SystemD е Линукската версия на svchost.exe - и се опитва да превърне Линукс в Уиндоус, заради мързеливи и неграмотни потребители и администратори. Поредното доказателство че корпорациите съсипват всяка хубава идея. Solaris и AIX имат много по-читави решения за менажиране на сървисите - SMF за Соларис и SRC за AIX. 
 

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
на 16.09.2019 г. в 21:08, ТерминалТора написа:

Проблемът със systemd е начина му на налагане и хилядите омотани депендънсита, разпиляни файлове и кофти документация. Systemd е наложен по един много фашистки начин, който не оставя на потребителя избор. А това противоречи с философията на отворения код да има избор. Освен това авторите са едни много неприятни типове,които дори не обръщат внимание на репортнатите бъгове. SystemD е Линукската версия на svchost.exe - и се опитва да превърне Линукс в Уиндоус, заради мързеливи и неграмотни потребители и администратори. Поредното доказателство че корпорациите съсипват всяка хубава идея. Solaris и AIX имат много по-читави решения за менажиране на сървисите - SMF за Соларис и SRC за AIX. 
 

А можеш ли да обясниш с какво по-точно SMF ( като идея говоря, не като имплементация ) е различен от SystemD? С SRC не съм се сблъсквал до сега, но SMF за мен е с почти 1-1 идея като  SystemD. Ако говорим за чистата имплементация, според мен INI стила на SystemD е по-четим от XML-a при писането на сървиси ( ако зависи от мен да го имплементирам - всичоко и навсякъде, за каквито и да е конфигурации трябва да е YAML, но това е друга тема ). 
Това за корпорациите също не го разбирам ( най-малкото си дал примери с IBM и ORACLE, като алтернативни решения ) - имаше алтернативи преди SystemD да се наложи ( Upstart/SystemV ).
Като цяло аз съм точно за налагане на стандарт на абстрацкия върху потребителите ( без значение - обикновен потребител/sysadmin etc. ). Това, че имаш стандарт на имплементация на сървиса - по никакъв начин не ти връзва ръцете за имплементацията на App-a, който ще стартираш през него. Дори напротив, дава ти стандартен и предиктивен начин на работа със ситемата ти.
При SystemV беше тотален shit положението, и сървиси се пишеха, на кой както му е кеф - predictability 0. 
За документацията - до някъде съм съгалсен, че е shit - но в скорошните release, man pages са ОК - поне според мен ( или аз съм привикнал с времето ).
Можеш ли да дадеш някакъв по-конкретен аргумент кое по-точно не е ОК според теб?
Колкото до авторите аз съм върл фен на Lennart Poettering - че маже кода, няма спор, ама идеите му са ОК, а и има кой да му оправя мазаляка ( в повечто случаи ). А и това пак е много-относително, защото примерно в kernel maling list-ите, ако проследиш дискусии - има доста по-големи мазаници, които се merge-ват upstream.
А това ,че има бъгове, които не са оправени много време, си а абсолютно нормална dev процедура. Ако, бъга няма директен security impact и не засяга голяма, част потребители - може да се отложи във времето, ако има лесен workaround - също. Ако за някой е голям проблем в тези случаи - може да си напише patch, или да наеме екип, който да го напише - за пример Facebook правят точно това, точно със SystemD и до колкото се сещам upstream-наха наскоро техни доработки.


Сподели този отговор


Линк към този отговор
Сподели в други сайтове
преди 2 часа, borovaka написа:

А можеш ли да обясниш с какво по-точно SMF ( като идея говоря, не като имплементация ) е различен от SystemD? С SRC не съм се сблъсквал до сега, но SMF за мен е с почти 1-1 идея като  SystemD. Ако говорим за чистата имплементация, според мен INI стила на SystemD е по-четим от XML-a при писането на сървиси ( ако зависи от мен да го имплементирам - всичоко и навсякъде, за каквито и да е конфигурации трябва да е YAML, но това е друга тема ). 
Това за корпорациите също не го разбирам ( най-малкото си дал примери с IBM и ORACLE, като алтернативни решения ) - имаше алтернативи преди SystemD да се наложи ( Upstart/SystemV ).
Като цяло аз съм точно за налагане на стандарт на абстрацкия върху потребителите ( без значение - обикновен потребител/sysadmin etc. ). Това, че имаш стандарт на имплементация на сървиса - по никакъв начин не ти връзва ръцете за имплементацията на App-a, който ще стартираш през него. Дори напротив, дава ти стандартен и предиктивен начин на работа със ситемата ти.
При SystemV беше тотален shit положението, и сървиси се пишеха, на кой както му е кеф - predictability 0. 
За документацията - до някъде съм съгалсен, че е shit - но в скорошните release, man pages са ОК - поне според мен ( или аз съм привикнал с времето ).
Можеш ли да дадеш някакъв по-конкретен аргумент кое по-точно не е ОК според теб?
Колкото до авторите аз съм върл фен на Lennart Poettering - че маже кода, няма спор, ама идеите му са ОК, а и има кой да му оправя мазаляка ( в повечто случаи ). А и това пак е много-относително, защото примерно в kernel maling list-ите, ако проследиш дискусии - има доста по-големи мазаници, които се merge-ват upstream.
А това ,че има бъгове, които не са оправени много време, си а абсолютно нормална dev процедура. Ако, бъга няма директен security impact и не засяга голяма, част потребители - може да се отложи във времето, ако има лесен workaround - също. Ако за някой е голям проблем в тези случаи - може да си напише patch, или да наеме екип, който да го напише - за пример Facebook правят точно това, точно със SystemD и до колкото се сещам upstream-наха наскоро техни доработки.

В Юникс добрата практика е една програма да прави само едно нещо,но да го прави като хората. SystemDisease е един огромен блоутъер и тумор,който освен да менажира сървисите се меси и на куп други места - виж systemd-logind , systemd-resolved и всичките ред хатски и гномски кочини. Счупи ли се нещо по системд зависва цялата система. SMF на Соларис, понe  няма хардкоднати депендънсита, Даже позволява ако ти е кеф , да си ползваш старите rc скриптове - при системд е просто симлинк към /bin/systemctl  . Когато едно нещо се прави, уж да улесни потребител/админ идиот, от това страда стабилността и сигурността на системата - пример Уиндоус. А Линукс доста сериозно се е запътил по кофти път. Нищо тамън ще се отвори шанс за доброто старо класическо BSD.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
на 4.09.2019 г. в 22:36, petie1 написа:

Нека в тази тема обсъждаме проблема със snap systemd и други подобни неддолюбвани неща за да не се пилее знанието по други теми

Аз така си помислих, че темата е за друго. Според заглавието, би трябвало да е как да си конфигурираш сървър Debian-а, че да не ти го хакнат след 15 мин.

преди 15 часа, ТерминалТора написа:

SystemDisease

:D +1

преди 17 часа, borovaka написа:

При SystemV беше тотален shit положението, и сървиси се пишеха, на кой както му е кеф - predictability 0.

Ако някой беше заменил SystemV навремето, сега дейстително нямаше нямаше да имаме "удоволствието" SystemD. Така че поне по тази точка си много прав.

...........................................

Ето една интересна, свързана новина:

Цитат

Debian May Need To Re-Evaluate Its Interest In "Init System Diversity"

Debian Project Leader Sam Hartman has shared his August 2019 notes where he outlines the frustrations and issues that have come up as a result of init system diversity with some developers still aiming to viably support systemd alternatives within Debian. 

https://www.phoronix.com/scan.php?page=news_item&px=Debian-Init-Diversity-Question

преди 15 часа, ТерминалТора написа:

Когато едно нещо се прави, уж да улесни потребител/админ идиот, от това страда стабилността и сигурността на системата - пример Уиндоус. А Линукс доста сериозно се е запътил по кофти път. Нищо тамън ще се отвори шанс за доброто старо класическо BSD.

И аз оставам с такова впечатление!

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
преди 2 часа, Melmak ® написа:
 
Аз така си помислих, че темата е за друго. Според заглавието, би трябвало да е как да си конфигурираш сървър Debian-а, че да не ти го хакнат след 15 мин.

И това може да обсъждаме защо не?

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Нещо интересно по темата за SystemD ( реално няма общо със SystemD, но това си е грешна стратегия от бая време на  Lennart) :

https://streaming.media.ccc.de/asg2019/relive/164

Идеята ми се вижда доста-добра. Проблем има примерно със SSH към машина на която не си логнат локално - след като home partition-a е заключен, реално не можем да направим SSH към дадения User. За това обаче си мисля, че има лесен Workaround, ако има 2 images - единия да е home.username а другия meta.username (който да държи примерно authorized_keys на потребителя ). Така може реално да се напарави SSH към dummy акаунт с рандом UID, който да има право единствено да отключи LUKS-a на съответния User. След това нещата са прости: su - username

Та какво мислите вие за идеята?
 

 

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
на 19.09.2019 г. в 22:01, petie1 написа:

И това може да обсъждаме защо не?

Да, принципно ме интересуват и двете.

преди 1 час, borovaka написа:

Та какво мислите вие за идеята?

Че казуса е интересен и пак пипа по чувствителни зони. :)  Навлиза в сферата на automation на заучени действия и по-скоро не би трябвало той да го прави.

на 19.09.2019 г. в 1:56, borovaka написа:

Можеш ли да дадеш някакъв по-конкретен аргумент кое по-точно не е ОК според теб?

Едно от нещата, които много ме съмняват е трябва ли да реализира събития и съобщения в SystemD. Струва ми се че е съществена грешка, защото може да се отделят и проблематиките там са достатъчно обширни и засукани. Демек невъзможно е да се реализират добре от първия път, какво остава ако програмата му прави четири сложни действия - управление на стартирането /състоянията/, сървиси, месинджинг и събития. Даже са много повече, но да не издребнявам излишно.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
преди 39 минути, Melmak ® написа:

Едно от нещата, които много ме съмняват е трябва ли да реализира събития и съобщения в SystemD. Струва ми се че е съществена грешка, защото може да се отделят и проблематиките там са достатъчно обширни и засукани. Демек невъзможно е да се реализират добре от първия път, какво остава ако програмата му прави четири сложни действия - управление на стартирането /състоянията/, сървиси, месинджинг и събития. Даже са много повече, но да не издребнявам излишно.

За SystemD като цяло ли говориш? Или само за Init часста?
Реално SystemD много отдавна не е само Init система

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
преди 8 часа, borovaka написа:

Нещо интересно по темата за SystemD ( реално няма общо със SystemD, но това си е грешна стратегия от бая време на  Lennart) :

https://streaming.media.ccc.de/asg2019/relive/164

Идеята ми се вижда доста-добра. Проблем има примерно със SSH към машина на която не си логнат локално - след като home partition-a е заключен, реално не можем да направим SSH към дадения User. За това обаче си мисля, че има лесен Workaround, ако има 2 images - единия да е home.username а другия meta.username (който да държи примерно authorized_keys на потребителя ). Така може реално да се напарави SSH към dummy акаунт с рандом UID, който да има право единствено да отключи LUKS-a на съответния User. След това нещата са прости: su - username

Та какво мислите вие за идеята?
 

 

Хем е добра хем не е като е писал Мелмак

преди 7 часа, Melmak ® написа:

Да, принципно ме интересуват и двете.

Темата е за това така че дерзайте

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
преди 21 часа, borovaka написа:

За SystemD като цяло ли говориш?

Да. За systemD като цяло.

преди 21 часа, borovaka написа:

Реално SystemD много отдавна не е само Init система

Хм, знам това. Ама понеже питаш какво поставяме под съмнение...

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Накратко за SystemD:

https://www.opennet.ru/openforum/vsluhforumID3/118577.html#20

Извинявам се, че е на руски език, но ми хареса краткото и точно описание на "проблема SystemD".

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
преди 1 час, p4p написа:

Накратко за SystemD:

https://www.opennet.ru/openforum/vsluhforumID3/118577.html#20

Извинявам се, че е на руски език, но ми хареса краткото и точно описание на "проблема SystemD".

Аз изобщо не съм съгласен с твърденията ( като изключим тези за бъговете и code quality :) )
Иначе, много ясно, че като имаш стандартизация - губиш някакво flexibility - реално не го губиш, защото в сървиса можеш да извикакш какъвто искаш код отдолу - той и пича го е писал, че за по нетипични неща му се налага да пилза скрипт/програма. Това обаче за мен си е чист benefit
По-скоро опираме от една страна до манталитет на Developer срещу SysAdmin/User, а от друга до чист hate към проекта и Ленарт.
1) Това, че един проект е OpenSource - не значи - повтарям не значи, че Main development team-a трябва да се съобразява с желания на community-то ( всеки има свободата да го форкне )
2) RedHat ще си правят каквото искат - имат капацитета/парите/development power-a да го правят - това, че стоят зад SystemD и зад Gnome като цяло им дава пълното право да си интегрират едното с другото както искат
3) Ако някой не се кефи на тези технологии - спокойно може да не ги ползва. Въпросът обаче е, че в крайна сметка всички ги adopt-наха, което е показателно
4) Този hate трябва да спре - реално в момента - всичко що е SystemD, идея на Ленард е кофти! Обаче ако някой се загледа в kernel кода, kernel mailing lista - там мазаляка е брутален за доста неща - обаче никой нищо не казва, защото алтернатива няма
5) Според мен - По-добре да имаш продукт с bad code quality, който да е стандартизиран и интегриран - по простата причина, че кода винаги може да се пренапише читаво, ако имаш изграден интерфейс, който се ползва. Другото е много по-сложно да имаш 1000 интерфейса, които всеки ползва както си иска
6) Що се отнася до INIT състема, стартъп скриптовете според мен трябва да са точно сървиси, с ясна дефиниция и без много волности. Ако има някакъв по-сложен сценарий логиката се оставя на програмиста на сътовтения app, който може да я изнесе в някаква bootstrap програма/скрипт, който да се call-не през сървиса - Това е правилния начин. Като администратор, ако отвориш даден service знаеш  какво ще е реално - структура ти е ясна, ако отвориш SystemV скрипт - почваш да се мъчиш да се ориентираш в мазаляка, който някой е решил да сътвори някога.
7) Тази стандартизация ти дава някои интересни свойства - Можеш да sandbox-неш сървиса, можеш да вкараш някакви firewall rules per service и т.н

Някой изобщо замисля ли се, че като прокламира постоянно Ричи-Томпсън философията на Unix от 70-те, е възможно не всичко да apply-ва към днешна дата?
Примерно да изключим SystemD, bash е удобен много, но от силна отживелица, като имплементация. PowerShell като идея е много по-добре измислен - като conversion-a на командите и аргументите към ясно дефинирани обекти, които имат някакъв ясен behavior. На мен bash ми е по-удоен като интерфейс за работа, въпроса е, че това не значи, че е по-добър като замисъл и имплементация (напротив кода е пълен shit ).

Та идеята ми е да не се заклеймява така effort-а на някой, било Ленард/RedHat/Microsoft/Google etc.
Ако някой не го кефи нещо да се спасява - има свободата да си форква, модефицира и да прави каквото иска - въпроса е дали effort-а си струва и дали ще е по-ОК неговата имплементация.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Бъх, като кликнах на темата и очаквах да видя нещо свързано с добрите практики при работата с линукс дистрибуции и нещо свързано с тяхната сигурност, а то какво се оказа - още една тема " Linux - обща дискусия  4"

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
на 16.09.2019 г. в 21:08, ТерминалТора написа:

SystemD е Линукската версия на svchost.exe
 

Когато бях с Уиндоуз, не знам какво ми пречеше този svchost.exe, а и не знаех какво върши - но все се опитвах да го убия през таск менеджера. :D

Сега, като отдавнашен ползвател на Линукс, с твоя помощ разбирам, че подсъзнателната ми агресия към svchost.exe е била права ;)

 

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
преди 7 часа, forticius написа:

Когато бях с Уиндоуз, не знам какво ми пречеше този svchost.exe, а и не знаех какво върши - но все се опитвах да го убия през таск менеджера. :D

Не мисля, че имат нещо общо, но пък все пак никой не знае какво прави svchost (без да се види кода), systemd е отворен код, не взема GB-ти и работи.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Добавете отговор

Можете да публикувате отговор сега и да се регистрирате по-късно. Ако имате регистрация, влезте в профила си за да публикувате от него.

Гост
Напишете отговор в тази тема...

×   Вмъкнахте текст, който съдържа форматиране.   Премахни форматирането на текста

  Разрешени са само 75 емотикони.

×   Съдържанието от линка беше вградено автоматично.   Премахни съдържанието и покажи само линк

×   Съдържанието, което сте написали преди беше възстановено..   Изтрий всичко

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Добави ново...