Skocz do zawartości
Śledziu

Teoria Panelu Administracyjnego Pod Linuksa

Polecane posty

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 :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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. ;)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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..

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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! :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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 ;)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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 :huh:

 

Pozdrawiam;

Szczepanik Adrian

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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!

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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 :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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 :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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.. :P

 

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

pozdr.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się


×