Jeśli przy połączeniu do serwera dochodzi do timeout, to można pomyśleć o zmianie wartości ConnectionTimeout w pliku /etc/ssh/ssh_config.
Otwórz ten plik edytorem, odszukaj linijki ConnectionTimeout, która domyślnie ma wartość 0 (i jest zakomentowana) i zmień jej wartość np. na wysokie 5m, np. tak:
sudo vi /etc/ssh/ssh_config
ConnectionTimeout 5m
Następnie zrestartuj serwis SSH:
sudo /etc/init.d/ssh restart
Gotowe!
Powershell Remoting albo działa albo nie 🙂 Ewentualne problemy moga się wiązać z filtrowanym ruchem sieciowym ale też z samą konfiguracją usługi WinRM, bezpieczeństwem i uwierzytelnieniem. Jeśli komputery stoją w tej samej domenie, to wiele rzeczy będzie działać „od strzału” ale jeśli komputery nie są w domenie, to mogą być problemy. Dlatego zobaczmy, jak skonfigurować remoting między lokalnym komputerem, a maszyną wirtualną w Azure.
Kliknij „Add inbound port rule” i zdefiniuj reguły pozwalające na połączenia skądkolwiek dokądkolwiek na portach 5985 i 5986:
Tworzymy tu obiekt opcji, w którym deklarujemy się zaakceptować self-signed certificate, następnie pobieramy nazwę użytkownika i hasło, po czym można utworzyć obiekt sesji. Ten obiekt sam w sobie zawiera już połączenie do zdalnej maszyny. Dlatego w następnym kroku, można już uruchomić Invoke-Command do zdalnej maszyny i zapytać ją jak się nazywa. Tą nazwę można porównać z nazwą lokalnego komputera. Nazwy powinny się różnić:
Oryginalna instrukcja:
https://techdiksha.com/configuring-winrm-azure-virtual-machine/
Zdarza mi się, że po spotkaniu/szkoleniu umówię się z uczestnikami, że otworzymy sobie wspólnego czata. Czasami czatować da się bezpośrednio w Teams w ramach czatu dostępnego podczas spotkania, ale niekiedy konfiguracja jest taka, że po spotkaniu czat znika i już.
Załóżmy więc, że mam po prostu 20 adresów email. Czy czeka mnie teraz wpisywanie każdego adresu do pola wyszukiwania i klikanie dla każdego uczestnika osobno? Wcale nie!
Można stworzyć odpowiedni URL o takiej oto postaci:
https://teams.microsoft.com/l/chat/0/0?users=bartek@adres1.com,borys@adres2.com,darek@adres3.com,&topicName=BurzaMozgow&message=Cześć!
Ot po prostu w parametrze users= należy podać rozdzielone przecinkami adresy email, po topicName podać nazwę grupki do utworzenia, a po message pierwsza wiadomość.
Kiedy adres URL będzie już gotowy, przeklej go do przeglądarki, naciśniej Enter i…. uruchomi się Teams z gotową do wysłania do wszystkich osób wiadomością. Popraw co trzeba, kliknij wyślij i gotowe!
Zwykle otrzymując komunikat ModuleNotFoundError wskazujący na jakąś tam nazwę np. tutaj sklearn rozwiązujemy problem komendą:
pip install sklearn
Ale w Python 3.x trzeba zainstalowć w tym przypadku inny moduł 🙂 – ot taka niespodzianka:
pip install scikit-learn
I niech błędy trzymają się od nas z daleka!
PG Admin daje możliwość zapisania haseł wykorzystywanych do połączenia się do serwerów PostgreSQL. Dzięki temu administrator nie musi ich wprowadzać za każdym razem na nowo. Czy to dobra praktyka, żeby najważniejsze hasła zapisać lokalnie na dysku (nawet w zaszyfrowanej postaci)? Powiedziałbym, że nie, ale się da…. Jeśli zapomnisz tego hasła do haseł (master password) to możesz je łatwo zresetować. Oto jak:
1 – Na stronie pytającej o master password wybierz „Reset Master Password”
2 – Potwierdź, że definitywnie nie pamiętasz master password i zgódź się na zapomnienie wszystkich pozostałych haseł (oznacza to tyle, że do kazdego serwera przy połączeniu trzeba będzie podać nazwę użytkownika i hasło):
3 – Teraz można zdefiniować nowy master password:
4 – Teraz przy połączeniu do serwera, trzeba podać hasło związane z tym serwerem i wybranym użytkownikiem. Mam nadzieję, że je pamiętasz, a jeśli nie, to zajrzyj tu: https://www.mobilo24.eu/postgresql-zapomniane-haslo-jak-zresetowac-haslo/
Zastosuj poniższą procedurę, jeśli zdarzyło Ci się zapomnieć hasła użytkownika postgres
1 – Znajdź plik pg_hba.conf. Ten plik określa zasady dotyczące tego kto i jak musi się uwierzytelnić przed serwerem:
2 – Za chwilę zmodyfikujesz ten plik, dobrym zwyczajem jest wykonanie kopii przed modyfikacją. Po całej procedurze wystarczy przywrócić oryginalny plik i będzie po sprawie. Następnie otwórz plik np. w notatniku i zamień w linijce rozpoczynającej się słowem host i zawierającej adres 127.0.0.1, tekst w ostatniej kolumnie. U mnie było tam wpisane scram-sha-256, a zaminiłem go na trust (oryginalna zawartość linijki jest zakomentowana powyżej zaznaczonej linii na obrazku poniżej. Nowa zawartosć linii jest zaznaczona). Ten wpis mówi o tym, że połączenie pochodzące z adresu 127.0.0.1 jest zaufane i nie pytamy o hasło!
3 – Plik należy zapisać. Żeby zmiany zostały wczytane przez PostgreSQL server, trzeba go zrestartować. Najpierw poszukaj programu services.msc. Kliknij na start i wpisz services.msc, a następnie klinij na services (w przypadku systemu operacyjnego z językiem polskim program nazywa się usługi):
4 – Teraz odszukaj usługi o nazwie PostgreSQL i uruchom ją ponownie:
5 – Pozostaje połączyć się do serwera i zmienić hasło. Możesz to zrobić z linii komend. Kliknij na start i wpisz cmd.exe. W cmd podaj ścieżkę dostępu do programu psql.exe i parametrami wskaż, że chcesz się połączyć do lokalnego serwera postgresql na porcie 5432 i na użytkownika postgres. Po połączeniu zmień hasło użytkownika postgres stosując polecenie ALTER USER postgres WITH PASSWORD 'password’;
6 – Hasło zostało zmienione. Zakończ sesję z postgresem i przywróć sprawdzanie hasła, tzn. przywróć oryginalną zawartość pliku pg_hba.conf i zrestartuj PostgreSQL jeszcze raz.
7 – Jeśli coś nie wyszło sprawdź w szczególności dane wprowadzone w pg_hba.conf: literówki itp. Możesz nawet wpisać słowo trust w kazdej linijce tego pliku zastępując aktualną zawartość, tylko pamiętaj, że taka konfiguracja jest w tym momencie bezbronna, tzn. nawet sesje zdalne mogą nie wymagać hasła. Trochę to ryzykowne, jeśli na serwerze są rzeczywiście jakieś ważne dane. Jeśli system jest zainstalowany na Unix, to logika kroków jest taka sama, tylko polecenia nieco inne 🙂
W moim przypadku, po odtworzeniu danych z laptopa (awaria komputera, ale była kopia yuppii!), większość aplikacji zarejestrowanych na koncie Microsoft uruchomiła się po zwyczajnym ponowieniu zalogowania (wyloguj/zaloguj i działa). Niestety los One Drive był inny. Po zalogowaniu dostawałem błąd 1200 – coś poszło nie tak i skontaktuj się z administratorem – no bez jaj, to ja jestem administratorem.
Operacje w rodzaju odinstaluj i zainstaluj też nie pomogły. W Internecie znalazłem wskazówkę, żeby usunąć zapisane hasła w managerze poświadczeń. Nie pomogło, ale jeśli chcesz spróbować:
>trzeba kliknąć na start
> poszukać panelu sterowania
> kliknąć konta użytkowników
> z boku wybrać polecenie „zarządzaj poświadczeniami”
> kliknąć „Poświadczenia systemu Windows”
> poszukać wszystkich poświadczeń, które miałyby w nazwie One Drive i usunąć je
Ale… idąc dalej znalazłem lepszą wskazówkę. Są dwa podejrzane foldery w profilu użytkownika Windows, w których też zapisuje się nieco informacji o użytkowniku i usunięcie ich może pomóc. Ponieważ zawsze jest lepiej mieć otwartą drogę do wycofania się z nieudanej naprawy, ja tych folderów nie usuwałem, tylko zmieniłem im nazwę. Zaczynamy od otwarcia exploratora plików, a następnie w pasku adresu wprowadzamy taką ścieżkę:
c:\users\twoja-nazwa-uzytkownika\AppData\Local\Microsoft
Tutaj powinny sie znajdować 2 foldery: IdentityCache i OneAuth. Zmieniłem im nazwę dodając rozszerzenie .old, ale jeśli masz odwagę to je usuń. Podobno nawet wystarczy zmienić nazwę tylko tego pierwszego z nich, czyli IdentityCache, ale ja zminiłem obie i pomogło, więc nie mam już szansy sprawdzić, czy trzeba to zrobić z obydwoma. W takim momencie dobrze jest przeprowadzić restart systemu. Po restarcie, uruchomiłem OneDrive, zalogowałem się, przeszedłem parę kroków z miłym kreatorem i pliki zaczęły się synchronizować. Po drodze wyskoczyło też kilka błędów, ale zawsze z opcją „Kontynuuj”, więc jak dla mnie nie było tak źle 🙂
https://answers.microsoft.com/en-us/msoffice/forum/all/onedrive-error-1200/977fc832-9e40-44ff-abca-74791bcddc96?page=2
