Administracja serwerami Linux Rzeszów

Do czego zakład używa Linuksa, skoro biuro siedzi w domenie?

Do ról, w których liczy się ciągła praca, przewidywalne zużycie zasobów i brak opłaty za każde kolejne połączenie. Logowanie i pliki biurowe zwykle zostają w Windowsie, a na Linuksie ląduje to, co obsługuje halę.

Najczęściej spotykamy cztery role. Serwer wymiany plików ze sterownikami obrabiarek, z którego maszyny pobierają programy i na który odsyłają wyniki. Maszyna zbierająca dane z produkcji, czyli odczyty ze sterowników, wyniki pomiarów i zdarzenia z systemów nadzorczych. Serwer przyjmujący kopie z pozostałych maszyn. Wreszcie brama sieciowa rozdzielająca segment maszynowy od biurowego i kończąca tunele do odbiorców, którzy wymagają wymiany dokumentacji kanałem zamkniętym.

Wspólną cechą tych ról jest to, że nikt na nie nie patrzy, dopóki działają, i że każda zatrzymuje pracę natychmiast, gdy przestanie. Dlatego progi w monitoringu ustawiamy tu ostrzej niż na maszynie, z której ktoś raz dziennie drukuje zestawienie.

Dlaczego serwer rozmawiający z obrabiarkami wymaga przestarzałych protokołów?

Bo sterownik maszyny kupionej dziesięć lat temu został zaprojektowany pod to, co było standardem w chwili jego powstania, a maszyna ma pracować jeszcze przez kolejną dekadę. Nikt nie wymieni sterownika za sześciocyfrową kwotę po to, żeby serwer plików mógł wyłączyć starą wersję protokołu.

To jest realny konflikt, a nie teoria, i rozwiązuje się go na poziomie sieci, nie na poziomie życzeń.

Czego wymaga sterownik	Na czym polega kłopot	Jak to zamykamy
Stara wersja protokołu udostępniania plików	znane podatności, brak szyfrowania	wyłącznie w segmencie maszyn, bez wyjścia dalej
FTP bez szyfrowania	hasło jedzie tekstem jawnym	konto o jednym zastosowaniu, dostęp z listy adresów
Stałe konto zapisane w sterowniku	nie da się zmieniać hasła co kwartał	konto bez praw poza swoim katalogiem, hasło w rejestrze
Brak obsługi nowoczesnego uwierzytelniania	nie wpina się do domeny	osobna baza kont po stronie serwera, nie w Active Directory
Zapis wyników w katalogu wspólnym	jedna maszyna widzi pliki drugiej	katalog na maszynę, uprawnienia rozdzielone
Brak logów po stronie sterownika	nie wiadomo, co pobrał	zapis operacji po stronie serwera, wysyłany poza maszynę

Zasada jest jedna i warto ją znać przed rozmową o sprzęcie: ryzyko przenosimy tam, gdzie da się je ograniczyć, czyli do sieci i do serwera. Sterownik zostaje taki, jaki jest, bo to on decyduje o zdolności produkcyjnej, a nie o polityce bezpieczeństwa.

Co się dzieje, gdy ktoś nadpisze program wysłany na maszynę?

W zakładzie, który powtarza serie po latach, to jest scenariusz droższy niż awaria dysku. Nadpisany program wygląda jak poprawny, uruchamia się bez błędu i daje detal różniący się od poprzedniej partii, co wychodzi dopiero na pomiarze albo, w gorszym wariancie, u odbiorcy.

Odpowiadamy na to trzema rzeczami po stronie serwera. Katalog z zatwierdzonymi programami jest tylko do odczytu dla stanowisk, a zapis idzie osobną drogą, przez człowieka odpowiedzialnego za technologię. Migawki wolumenu robione w ciągu dnia pozwalają wrócić do wersji sprzed nadpisania bez odtwarzania kopii z nocy. Do tego zapisujemy sumę kontrolną pliku wydanego na maszynę, więc pytanie, czy detal powstał z tej samej wersji programu co poprzednia partia, przestaje być pytaniem o czyjąś pamięć.

Reszta zależy od sposobu pracy, nie od konfiguracji, i mówimy to otwarcie. Serwer plików nie zna procesu zatwierdzania zmian, więc jeżeli w zakładzie program poprawia się prosto na hali, żadna migawka tego nie uporządkuje.

Jak zbieramy dane z maszyn, nie dokładając im pracy?

Ostrożnie i zawsze w jedną stronę. Maszyna produkcyjna nie jest źródłem danych, tylko urządzeniem, które przy okazji je udostępnia, i ta kolejność musi być widoczna w konfiguracji.

Odczyt prowadzimy z konta bez prawa zapisu, w odstępach ustalonych z utrzymaniem ruchu, i zapisujemy wynik na osobnej maszynie, a nie na tej, która obsługuje wymianę plików. Dzięki temu zatrzymanie zbierania danych nie ma żadnego wpływu na produkcję, a zatrzymanie produkcji jest w danych widoczne, zamiast je psuć. Wszystko, co wychodzi z tej maszyny do raportów dla odbiorcy, idzie z kopii, nie z odczytu na żywo.

Ta warstwa zwraca się szybciej niż większość zakupów oprogramowania, ponieważ zestawienie składane ręcznie przez dwa dni na koniec miesiąca przestaje istnieć jako zadanie. Samo składanie raportu w formacie wymaganym przez odbiorcę jest już inną usługą niż utrzymanie serwera i wyceniamy je osobno.

Kto ma klucz do tego serwera i jak to sprawdzić?

Odpowiedź musi być zapisana, nie pamiętana, bo przy audycie łańcucha dostaw pytanie o dostęp pada zawsze. Prowadzimy więc listę kont z przypisaniem do nazwiska i do roli, a nie do stanowiska pracy.

Wejście odbywa się kluczem, logowanie hasłem na konto roota jest wyłączone, a każde polecenie wykonane z podniesionymi uprawnieniami trafia do dziennika wysyłanego na inną maszynę. Jest to zabezpieczenie przed dwoma różnymi sytuacjami: przed pomyłką, po której trzeba odtworzyć kolejność zdarzeń, i przed kimś, kto skasuje logi razem ze śladami swojej obecności.

Raz na kwartał przeglądamy tę listę razem z Wami i usuwamy konta, które przestały mieć powód istnienia: serwisant po zakończonym wdrożeniu, pracownik po zmianie stanowiska, integrator po odbiorze linii. Wpis o usunięciu trafia do rejestru zmian, więc rok później da się pokazać nie tylko to, kto ma dostęp dzisiaj, ale też to, kiedy przestał go mieć ktoś inny.

Serwery z domeną i aplikacjami Microsoftu stoją obok, pod opieką opisaną przy administracji Windows Server. Węzły, na których te maszyny pracują, bierze wirtualizacja serwerów, a cały zakres umowy administracja serwerami. Stawkę wyliczy kalkulator.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026