Dziwna sprawa. W PowerShellu utworzony ScheduledTask nie uruchamia się. PowerShell go widzi, ale nie wiadomo, co powoduje, że zaplanowane zadania nie startują. Oto kod tworzący taki przykładowy job:

Dokładniejsza analiza logu harmonogramu zadań wskazała, że przyczyną jest brak uprawnień. Dziwne, bo polecenia uruchamiał lokalny administrator. Niestety konto tego administratora pochodziło z Azure AD. Ponieważ na komputerze jest jeszcze zdefiniowane inne konto administratora, to najprostszym rozwiązaniem było wskazanie, że zadanie ma się uruchamiać z wykorzystaniem tego innego konta. Na to inne konto można wskazać parametrem credential:

I teraz program działa jak ta lala. Jeśli zechcesz je usunąć wykonaj”

Task Scheduler lub po polsku Harmonogram Zadań służy do planowania i wykonywania powtarzalnych zadań na systemie. Narzędzie samo w sobie jest bardzo użyteczne… o ile działa… A jak nie działa? Do sprawdzenia wyników, warto by zajrzeć do historii wywołań takiego zadania. Historię można znaleźć przechodząc do określonego zadania w Harmonogramie. Problem w tym, że często ta historia jest wyłączona:

Włączenie historii jest proste, ale trzeba bardzo uważnie klikać myszką. Obawiam się, że projektanci aplikacji mogli by nieco poprawić usability tego programu. Należy kliknąć prawym przyciskiem myszy na „Task Scheduler” i wybrać polecenie „Enable All Tasks History”. Zazwyczaj kiedy tam klikasz, tej pozycji nie ma w menu! Skandal! Żeby polecenie było widoczne kliknij najpierw lewym przyciskiem myszy na Task Scheduler. W centralnej części okna pojawi się wtedy podsumowanie statusu zadań (okno startowe programu). Dopiero kolejne kliknięcie spowoduje, że w menu pojawi się poszukiwana opcja.

Po jej wybraniu właściwie od razu będzie można przeglądać historię uruchamianych zadań.

Linux to świetny system na Workstation, ale jeszcze lepszy na serwer. W przypadku serwerów często decydujemy się na zmianę adresu IP na stały. Oto jak to zrobić z wykorzystaniem polecenia nmcli:

np.

Zazwyczaj największym „problemem” jest odnalezienie nazwy profilu połączenia, a tymczasem jest to proste 🙂

Polecenie

wyświetla urządzenia interfejsów sieciowych i ich aktualne adresy IP. Z tego polecenia należy zapamiętać nazwę urządzenia (np eth0)

Polecenie

wyświetla nazwy profili przypisane do poszczególnych urządzeń. Wystarczy więc odczytać nazwę profilu połączenia stowarzyszoną z urządzeniem sieciowym (np. Wired Connection 1)

Jeśli nazwa profilu zawiera spacje, to w poleceniu nmcli należy te spacje poprzedzać znakiem \ (backslash), np. Wired\ Connection\ 1

Po wykonaniu w/w polecenia nmcli, nowa konfiguracja zostaje zapisana w plikach konfiguracyjnych Network Managera, ale nie jest ona od razu aktywowana. W celu ponownego zastosowania już nowej konfiguracji należy podnieść interfejs sieciowy:

Tym razem rozbudowałem ścieżkę edukacyjną Linux. Po kursie Linux-a  dla początkujących pora na pierwszy kurs administratora Linux-a!

Kurs Administrator Linux: Instalacja i konfiguracja składa się z głównych pięciu elementów:

1. Instalacja systemu
2. Konfiguracja sieci
3. Konfiguracja usług systemu przez systemd
4. Konfiguracja i zarządzanie dyskami
5. Proces bootwania i konfiguracja GRUB

Jak zwykle starałem się dostarczyć maksymalnie dużo przykładów, zadań do samodzielnego rozwiązania (z odpowiedziami) i quizów. Zapraszam!

Aplikacja jest dostępna  na CDROM, a właściwie była, bo płyta została przekopiowana z CDROM na dysk. Po uruchomieniu startera aplikacji niestety zamiast okienka aplikacji wyskakiwał błąd:

Application failed to start. Contact *** for details. Error code 662

Aplikacja nie była uruchamiana już chyba od ponad roku, więc właściwie przyczyną mogło być wszystko – zaczynając od odinstalowania wymaganego komponentu, instalacja konfliktowej łatki windows itp. Tym razem było jednak inaczej. Aplikacja oczekiwała określonej daty na komputerze – to ciekawe, bo podczas zakupu programu nie było mowy o tym, że będzie on działać tylko przez określony czas! Przy okazji trzeba pamiętać:

• do zmiany czasu wymagane jest uprawnienie administratora (albo odpowiednie prawo)
• zmiana czasu jest co do zasady złym pomysłem, bo może wtedy przestać działać automatyczne przywracanie systemu, kopie zapasowe, uwierzytelnienie certyfikatami i wiele wiele innych rzeczy, więc jeśli już zmieniać czas to robić to na jak najkrótszą chwilę
• aplikacja sprawdza czas tylko podczas uruchomienia, a nie w czasie pracy, więc wystarczy zmieniać czas na kilka/kilkanaście sekund podczas startu
• czas może wrócić do  poprzednich ustawień, jeśli synchronizacja jest włączona

Zmiana czasu w sposób interaktywny jest męczącą, trzeba się przeklikać przez wiele okienek, dlatego wymyśliłem, że zrobię to skryptem uruchamianym „jako administrator”. Pomysł jest następujący:

• wyliczymy czas 2 lata wstecz –  gdyby to było za mało, to można zmienić na 3, 4 itd. lub przypisać datę na stałe
• zmienimy ustawienia synchronizacji czasu w bezpośrednio rejestrze na „NoSync”
• przestawimy datę
• uruchomimy aplikację – zmień ścieżkę na właściwą
• zatrzymamy skrypt na np. 15 sekund – można zmienić zależnie od potrzeb
• potem wrócimy do starej daty. Będzie ona o 15 sekund nieaktualna, ale ponieważ za chwilę włączymy synchronizację czasu, to problem rozwiąże się sam, a 15 sekund nie jest aż takim problemem. Ewentualnie w tym miejscu można by dodać 15 sekund lub nawet uruchomić ręczną synchronizację czasu
• ostatni krok, to włączenie synchronizacji bezpośrednio w rejestrze na „NTP”

I to wszystko! Aplikację należy uruchomić przy pomocy skrótu, jako administrator. Aplikacja przy starcie odczytuje zmieniony czas i przechodzi do kolejnych kroków uruchomienia, a gdy już działa… czas wraca do poprzedniej wartości

Do stacji z RedHat-em łączę się z poziomu stacji Windows wykorzystując Putty i SSH. Wszystko działa, ale po wprowadzeniu nazwy użytkownika i naciśnięciu enter, muszę poczekać, chyba co najmniej około minuty, aż pojawi się pytanie o hasło. What is going on?

SSH z wersji na wersję zabezpiecza się przed potencjalnymi próbami hakowania połączeń i niektóre z opcji w tak prostym środowisku jak moje, nie mogły zostać spełnione. Serwer SSH czekał na wykonanie dodatkowych testów, ale niestety dochodziło do timeout-ów i dopiero kiedy wszystkie możliwości zostały wyczerpane przechodził do etapu pytania o hasło.

Co można wyłączyć:

zmień opcję UseDNS na no. U mnie wystarczyło odkomentować linijkę:

zmień opcję GSSAPIAuthentication na no.  U mnie ta opcja była ustawiona na yes, więc musiałem ja zmienić:

Po wszystkim zrestartuj demona sshd:

U mnie pomogło. A u Ciebie?

Remoting służy do uruchamiania poleceń na zdalnym komputerze. Zdarza się jednak, że chcesz przetestować połączenie na lokalnym komputerze, czyli przez remoting połączyć się ze swojego komputera na swój komputer. Jak to zrobić?

Twój lokalny komputer ma kilka nazw, które można wykorzystać łącząc się do niego:

• localhost
• 127.0.0.1
• $env:COMPUTERNAME

Niestety polecenie w takiej postaci:

Kończy się błędem:

[localhost] Connecting to remote server localhost failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting
Help topic.
+ CategoryInfo : OpenError: (localhost:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : AccessDenied,PSSessionStateBroken

Dlaczego? Jestem administratorem i nie mam uprawnień? Przecież domyślnie, jeśli nie przekazuję innych credentials, to połączenie jest wykonywane w bieżącym kontekście bezpieczeństwa. Najprawdopodobniej wiąże się to z tym, że połączenie może wykonywać tylko administrator, a przy połączeniu do serwera zdalnego twoje konto traci token administratora. Da się to jednak prosto obejść! Wystarczy do polecenia dodać parametr credential i wskazać, że połączenie zdalne ma być wykonywane w jego kontekście bezpieczeństwa, o tak:

Takie świeżo pobrane poświadczenia pozwolą pomyślnie wykonać połączenie, które domyślnie jest dostępne tylko dla administratorów