Teoria Panelu Administracyjnego Pod Linuksa

[Śledziu 0]

Potrzebuję napisać prosty zestaw skryptów w PHP do 'zarządzania' stacją linuksową (dodawanie/usuwanie userów, wyświetlanie aktywnych procesów, czyli nic zbyt skomplikowanego).

 

I szukam w miarę bezpiecznego rozwiązania. Jedyne co w tej chwili znam to wywoływanie poleceń za pomocą exec() czy system(), a to raczej nie jest zbyt dobre rozwiązanie. Macie jakieś pomysły? Może wprowadzić jakiś zestaw skryptów (w jakim języku? - ew. się doszkolę ) pośredniczących w wykonywaniu poleceń.

 

Liczę na was

[hyhyhy 0]

Ja bym postawił na perl lub python, albo to i to Php jak najbardziej - nie A słyszałeś o takim fajnym paneliku - webmin? Pozdr.

[Śledziu 0]

Nie chcę webmina Mam po prostu w domu maszynę na linuxie, a że znam dobrze php to chcę to zrobić w php, perl odpada. Po prostu taki mój mały projekcik, na własne potrzeby, robiony z nudów

Myślałem aby aplikacja napisana w pythonie pośredniczyła w wykonywania poleceń. Gdzieś czytałem o takim rozwiązaniu. Perl można skreślić Ale chętnie posłucham o wszelkich możliwościach.

[beliq 442]

To może zrobisz to sposobem panelu VHCS?

Napisz w Pythonie daemona słuchającego na jakimś niestandardowym porcie (np. 9876) interfejsu lokalnego(127.0.0.1),

który w zależności od otrzymanego żądania wykonuje to i owo,

po czym zwraca wynik aplikacji napisanej w PHP.

 

P.S. Sam dzisiaj myślę nad pewnym panelem.

[Gość Bartosz Gadzimski]

Ja proponuję żeby aplikacja ustawiała zmienne w pliku, a całość była uaktualniana z cron'a jako skrypt powłoki lub podobny z prawami np. root'a.

 

Wtedy powinno być całkiem bezpiecznie.

[Śledziu 0]

bellerofont: myślałem właśnie nad takim rozwiązaniem, choć się zastanawiam jeszcze nad rozwiązaniem Bartosza Drugi jest znacznie prostszy do wykonania, i na podobnej zasadzie działa SysCP. Muszę się zastanowić nad tym..

[beliq 442]

bellerofont: myślałem właśnie nad takim rozwiązaniem, choć się zastanawiam jeszcze nad rozwiązaniem Bartosza Drugi jest znacznie prostszy do wykonania, i na podobnej zasadzie działa SysCP. Muszę się zastanowić nad tym..

Wiem jak ten panel działa, bo sam go używam.

Pomysł z cronem jest dobry, sprawdza się przy dodawaniu/usuwaniu użytkowników/kont/baz,

ale nie nadaje się to moim zdaniem do monitorowania procesów działających na serwerze

z tego względu, iz dane na ich temat byłyby aktualizowane tylko co pewien okres czasu;

1/3/5/10 minut w zależnośći od tego jaki zostanie dodany wpis do crona.

No ale... może Tobie to wystarczy.

[Gość patrick]

Możesz zrobić coś ala confixx czyli panel w php i skrypty perl'a wywoływane w cronie. Bądź myśleć nad jakąś aplikacją w całości np. w pythonie jak google.

ps. skrypt takiego confixxa masz na stronie swsoftu.

[ertcap 0]

1. Osobny serwer www z osobnym php (lub tez serwer www potrafiajacy zrobic setuid - suexec, mod_diffprivs, itd) + sudo + komenda exec w w phpie.

Rozwiazanie najlatwiejsze ale jak popelnisz gdzies blad w kodzie (ktory wyswietla sie userowi w przegladarce) to miales po serwerku

 

2. Aplikacja php robi wpisy gdzies do pliku txt - i raz na minute odpalany jest skrypt z crona (na poziomie roota), ktory wykonuje zadania. Rozwiazanie duzo bezpieczniejsze (nawet jak ktos zdobedzie kontrole nad Twoja aplikacja to raczej nic nie bedzie wstanie zrobic). Minus - na kazde zmiane trzeba czekac minimum minute.

 

3. Najbardziej pracochlonne - ale chyba najlepsze - aplikacja php laczy sie na jakis port z inna aplikacja sluchajaca tylko lokalnie, ktora biega na prawach roota (lub tez korzysta z sudo) i wykonuje zadania. Ta aplikacja moze byc napisana od zera jako program w np. C ale moze tez byc osobnym serwerem www z osobnym phpem.

 

To tak w telegraficznym skrocie.

Rozwiazanie trzecie ma jeszcze taki plus, ze mozna cos takiego bardzo ladnie skalowac - na jednym serwerze mamy aplikacje w phpie dla klienta a na innych mamy koncowki z ta aplikacja wykonujaca zadania.

 

pzdr.

[p 3]

Skrypt cgi napisany w C - nie bedziesz ograniczony funkcjonalnoscia API poszczegolnych jezykow wyzszego stopnia.

Jak nie czujesz sie na silach to wspomniane juz Python i Perl sie tez doskonale nadaja, chociaz jak nie znasz Perl'a to lepiej go nie ruszaj, bo strasznie latwo popelnic blad

No i PHP mowimy stanowczo NIE!

[Śledziu 0]

Spróbuję pobawić się pythonem, nie wydaje mi się on jakoś szczególnie trudny do nauki, a w necie jest całkiem sporo materiałów mu poświęconych.

Może być ciekawie.

 

 

Jak nie wyjdzie, to cron pójdzie do boju

[CinkowskiW 0]

A co powiecie na to, że Progreso.pl ma swój panel w PHP? Co prawda nie wiem jak to jest rozwiązane.

[MasterNETpl 100]

A co mamy powiedzieć czy co w tym dziwnego?

Chociaż na pewno pewne funkcje zbudowane sa na cgi, perl, python, etc... których zwykły użytkownik tego nie widzi

 

Pozdrawiam;

Szczepanik Adrian

[Śledziu 0]

Adrian Szczepanik: a jak to wygląda u Ciebie? W końcu korzystasz z autorskiego panelu, w jaki sposób on działa. Odpala coś zewnętrznego czt wszystko się dzieje via php?

[MasterNETpl 100]

Oczywiście php, cgi, perl + drobny bash.

Przykro mi ale dokładnej budowy oraz zasady działania nie mogę zdradzić.

[cyberluk 0]

A może _tu wstaw język programowania_ + SOAP + SUDO jako serwer poleceń dla panela. Do tego panel napisany też w _tu wstaw język programowania_? Tak będzie stabilnie i bezpiecznie - wymyślanie swojego protokołu do komunikacji panel<->daemon przez kogoś kto się uczy programować z założenia jest chore B) Jak już robić, to porządnie. No i starałbym się jak najwięcej funkcji napisać samemu po stronie daemona np. odczytywanie uptime nie na zasadzie pipe>bash>uptime i parsowanie, tylko wyciągnięcie z odpowiedniego miejsca informacji i odpowiednia prezentacja.

 

I dlaczego nie PHP? Sorry, ale błędy w oprogramowaniu wynikają z braku umiejętności programisty, a nie wad języka. Źle napisany kod w C, Perlu czy PHP będzie dokładnie tak samo szkodliwy. Różnica polega na prostocie i szybkości pisania - skrajne przypadki PHP vs C...

 

Ja bym proponował pisać oba moduły w PHP, ale... no właśnie zwracając uwagę na _bezpieczne_ programowanie!

[beliq 442]

Dam Ci radę... być na forum mógł żyć spokojnie:

Z P nie dyskutuj, bo jego mama już od świąt klęczy na grochu za nieznajomość RFC,

jak będziesz chciał polecić komuś jakiś system operacyjny to pamiętaj że na świecie istnieje tylko OpenBSD,

a wśród języków skryptowych tylko Perl. B)

[cyberluk 0]

Dam Ci radę... być na forum mógł żyć spokojnie:

Z P nie dyskutuj, bo jego mama już od świąt klęczy na grochu za nieznajomość RFC,

jak będziesz chciał polecić komuś jakiś system operacyjny to pamiętaj że na świecie istnieje tylko OpenBSD,

a wśród języków skryptowych tylko Perl.

 

O, to moja już przestała B) Teraz już zna RFC. A tak poważnie to ja ten etap przechodziłem z 3 lata temu... Już się na szczęście wyleczyłem Od momentu kiedy mam dostęp do fajnych zabawek, zrozumiałem, że to nie dane rozwiązanie należy dopasować do sprzętu - to sprzęt ma służyć realizacji danego projektu Z mojej strony życzę tego wszystkim O wiele lepiej się wymyśla nowe rozwiązania.

 

A co do OpenBSD - i tak "jego ojciec" jest lepszy

[Śledziu 0]

cyberluk: o SOAP(/XML-RPC) myślałem praktycznie od samego początku kiedy zdecydowałem się na napisanie 'platformy' pomiędzy php a serwerem. Jednak na razie (i długo tak pozostanie) projekt jest w fazie koncepcyjnej, gdyż na uczelni mam taki zapieprz że nie wyrabiam, a dodatkowo musiałbym się dokształcić w kwestii pythona, a teraz nie mam po prostu na to czasu.

[p 3]

I dlaczego nie PHP? Sorry, ale błędy w oprogramowaniu wynikają z braku umiejętności programisty, a nie wad języka. Źle napisany kod w C, Perlu czy PHP będzie dokładnie tak samo szkodliwy. Różnica polega na prostocie i szybkości pisania - skrajne przypadki PHP vs C...

Sorry, ale nawet jezeli napiszesz dobry program, a okaze sie, ze funkcje z ktorych korzystales sa podatne np. na DoS to bledy wynikaja z wad jezyka.

A PHP vs C to wcale nie sa skrajne przypadki. Sa nawet dosyc dalekie od skrajnosci...

 

Dam Ci radę... być na forum mógł żyć spokojnie:

Milcz B)

[cyberluk 0]

Sorry, ale nawet jezeli napiszesz dobry program, a okaze sie, ze funkcje z ktorych korzystales sa podatne np. na DoS to bledy wynikaja z wad jezyka.

A PHP vs C to wcale nie sa skrajne przypadki. Sa nawet dosyc dalekie od skrajnosci...

Jeżeli funkcja jest podatna na DoS, to zazwyczaj jest wina to kompilatora, który generuje zły kod, albo - zła implementacja funkcji w bibliotece (jeżeli lib'y są binarne). Na dokładnie takim samym poziomie podatne może być C, Perl, PHP czy Java. Nie oszukujmy się - większość błędów wynika z błędnie napisane kodu, a co za tym idzie z błędnie wykorzystanych funkcji danego języka (to jest co innego niż błędy w samej fukncji).

 

Jeżeli chodzi o PHP i C to chodziło mi o:

- szybkość pisania kodu C vs PHP

- złożoność kodu C vs PHP

- wydajność tego kodu C vs PHP

Jedyna wspólna cecha, to łatwość popełnienia błędów w obu tych językach - chociaż błędy te będą zupełnie innego typu B)

Nie róbmy już OT Kolega pytał o rozwiązanie i to zostało mu podsunięte

[Gość adamszendzielorz]

A co powiecie na to, że Progreso.pl ma swój panel w PHP? Co prawda nie wiem jak to jest rozwiązane.

 

O nie, nie nie!

 

Jadro extranetu dziala w perlu. To jest jakies 60% kodu. Dziala jako zwykly daemon po tcp/ip (Net::Server), zreszta mozna sobie wykonac:

 

telnet extranet.progreso.pl 2001

 

Przywita Cie serce calego extranetu.

 

Kolejne 20% kodu to rowniez perlowe skrypty wykonawcze na serwerach klienckich - wisza sobie na portach w okolicach 2000-2500 (ten sam mechanizm Net::Server) i nasluchuja po tcp/ip polaczen z serwera extranetu - one ogolnie smigaja na prawach roota i wykonuja wszystko co im extranet kaze zrobic (w gruncie rzeczy to one odwalaja cala czarna robote, sam extranet "tylko" tym sobie steruje).

 

I ostatnie 20% kodu to w koncu PHP - to juz jest sama koncowka GUI extranetu. Nawet jakby ktos znalazl bledy w tych skryptach - nic zlego nie zrobi -> caly PHP komunikuje sie w 100% przez API extranetu (te na porcie 2001).

 

Calosc ma zalety i wady.. Glowne zalety to to, ze extranet moze obslugiwac dowolna liczbe maszyn klienckich oraz bezpieczenstwo (procedury bezpieczenstwa sprawdzane sa na kazdym z trzech krokow -> skryptami PHP w koncowce klienckiej, w jadrze extranetu i w koncu na koncowych skryptach wykonawczych). To niestety niesie ze soba glowna wade - szybkosc. Extranet nie powala predkoscia dzialania, szczegolnie ze 95% rzeczy robi sie tam w czasie rzeczywistym. Ale nie jest znowu tak zle, a pracujemy obecnie ostro nad wprowadzeniem mechanizmow keszujacych i optymalizacja procedur bezpieczenstwa, czesc rzeczy bedzie tez bardziej statyczna (sa rzeczy ktorych uzytkownik nawet nie zauwaza, a sprawdzenie ich biezacego stanu trwa np sekunde..

 

No.. Extranet to jeden z moich dzieciakow wiec chetnie sie nim chwale.. Jakby ktos mial jeszcze jakies pytania - chetnie odpowiem ;-)

pozdr.

[foo 0]

Mozna tez php + system + shell_exec/exec

[Gość adamszendzielorz]

Mozna tez php + system + shell_exec/exec

 

I jak znajdzie sie dziura w PHP (a to jest bardzo prawdopodobne) to masz po wszystkim... To co proponujesz to jedna z najmniej bezpiecznych opcji

pozdr.

[foo 0]

Stąd ten

pozdr.