Masz taki błąd?

Zadanie „user@domain.pl – Odbieranie” zgłosiło błąd (0x800CCC1A): „Serwer nie obsługuje określonego typu szyfrowania połączenia. Spróbuj zmienić metodę szyfrowania. Aby uzyskać dodatkową pomoc, skontaktuj się z administratorem serwera poczty lub usługodawcą internetowym.”

I zepsuło się samo?

I nic nie zmieniałeś/aś?

Używasz „od zawsze” tego konta i zawsze działało?

I dzisiaj przestało?

Jedno konto działa, a inne nie, albo zepsuły się wszystkie?

Na telefonie nadal działa?

Na innych stronach radzą naprawiać plik pst, zmieniać numery portów albo instalować aktualizacje?

To powiem tak – chociaż lubię Microsoft i uważam system Windows i Outlook za bardzo dopracowane, to jednak czasami…. zwykły restart komputera potrafi zdziałać cuda.

Weź chłopie zrestartuj komputer (najlepiej przytrzymując klawisz Shift, co powoduje pełny restart). W każdym razie u mnie już działa

Domyślnie komendy i podkomendy dla terraforma trzeba znać, ale… można też pozwolić nauczyć się ich shellowi BASH (co dotyczy oczywiście tylko tych użytkowników, którzy pracują z BASHem).

Wystarczy wpisać polecenie:

terraform --install-autocomplete

Po tej komendzie wymagany jest restart shell-a lub ponowne wczytanie profilu, a potem…. po wpisaniu komendy terraform można nacisnąć tabulator raz lub dwa razy i zobaczysz podpowiedź, co można w swoim poleceniu napisać dalej:

AZ-104 to pierwszy profesjonalny egzamin na drodze administratora i architekta Azure. Ma on opinię dość ciężkiego egzaminu, bo pytania dotyczą szerokiego zakresu wiedzy, a tytuł administratora Azure, który zdobywa się po tym egzaminie zobowiązuje do dość szczegółowej wiedzy.

Dla wszystkich kandydatów przygotowaliśmy już drugi kurs przygotowujący: „AZ-104 Administrator Azure – Identity & Governance„.

Główne tematy kursu to:

• Wprowadzenie do Entra ID (Azure Active Directory)
• Zarządzanie użytkownikami i grupami, a w szczególności:
  • konta gości
  • service principal
  • managed identity
  • grupy dynamiczne
  • automatyzacja w wykorzystaniem powershella i bulk operations
• Porównanie licencji
• Jednostki organizacyjne
• Urządzenia w EntraID
• Zarządzanie w skali:
  • Resource Group, Subscription, Management Group
  • Koszty i budżety
  • Policy i Initative
  • Self Password Reset
  • Access Review
• Uprawnienia RBAC i role, w tym tworzenie custom rules
• Bezpieczeństwo:
  • Multifactor authentication
  • Conditional Access

Drugi kurs, a właściwie pierwszy, bo był wydany wcześniej to „AZ-104 Administrator Azure – Storage„.

Łącznie oba kursy pokrywają już ponad 60% materiału wymaganego do opanowania na egzamin. Wszystko z licznymi przykładami, testami, po polsku i z nutką humoru.

Zapraszamy!

Chcesz skonfigurować drukarkę, żeby automatycznie wysyłała faksy? A może chcesz codziennie dostać na maila raport o ilości wolnego dysku na domowym serwerze? A może po prostu chcesz z poziomu programu, czy skryptu wysłać sobie maila? W takim przypadku musisz skonfigurować, drukarkę, czy skrypt do korzystania z serwera SMTP. Jest jednak drobny problem. Ileś tam lat temu, żeby wysłać maila wystarczyło znać nazwę użytkownika i hasło i było to mocno wykorzystywane przez spamerów. Dlatego konfiguracja SMTP jest chyba obecnie jedną z najcięższych dla administratora, a i dla programisty wiele się zmieniło. Jeśli chcesz użyć SMTP programistycznie musisz wygenerować sobie odpowiedni token, tzw. application password. Tutaj pokażę, jak to zrobić z kontem GMAIL.

1. Udaj się na https://security.google.com/settings/security/apppasswords. Jest to strona, która pozwala zdefiniować app passwords. Jednym z utrudnień dla spamerów ma być to, że wszelkie automaty używające Twojego konta pocztowego powinny mieć swoje hasła, nie mogą one korzystać z hasła, jakim zabezpieczasz całe swoje konto.
2. Wymyśl jakąć nazwę aplikacji, np. „Drukarka Xerox” albo „Mój skrypt XYZ”. Po kliknięciu Create zostanie wyświetlone hasło.
   
   Uwaga: hasłem są poszczególne literki/cyferki, spacje między nimi już nie.
3. Teraz przejdź do konfiguracji poczty wychodzącej Twojej drukarki, albo skryptu. Np. ustawienia na mojej drukarce są takie:
   
   a tak wygląda konfiguracja connectora email na Azure:
   
   a tak wygląda skrypt w pythonie:
   

import smtplib
 
mailFrom = 'Your automation system'
mailTo = ['XXX@wp.pl','YYY@gmail.com']
mailSubject = 'Processing finished successfully'
mailBody = '''Hello
This mail confirms that processing has finished without problems,
Have a nice day!'''
 
message = '''From: {}
Subject: {}
 
{}
'''.format(mailFrom, mailSubject, mailBody)
 
user = 'my_user@gmail.com'
password = '***********'
 
server = smtplib.SMTP_SSL('smtp.gmail.com', 465)
server.ehlo()
server.login(user,password)
server.sendmail(user, mailTo, message)
server.close()
print('mail sent')

W Azure mamy dwa rodzaje logic apps: consumption i standard. Z zewnątrz oba wyglądają podobnie, bo i nazwa taka sama i sposób budowy aplikacji podobny, więc w czym problem?

Otóż okazuje sie, że wewnętrzenie te dwa modele logic app to coś zupełnie innego. O ile consumption to rzeczywiście usługa serverless, już wstępnie skonfigurowana i z tonami dokumentacji, o tyle standard jest właściwie aplikacją webową z przydzielonymi zasobami compute i wymaga dodatkowej konfiguracji niemal na każdym kroku, tymczasem z dokumentacją jest…. tak jakby nieco gorzej.

Jeden z problemów polega na tym, że logic app standard workflow stateless nie posiada historii! Nie widać kiedy się uruchomił workflow i co robił, kiedy już się go udało uruchomić.

Jest na to rozwiązanie wskazane o tutaj: https://learn.microsoft.com/en-us/azure/logic-apps/create-single-tenant-workflows-azure-portal#enable-run-history-for-stateless-workflows

W settings >> configuration należy samodzielnie dodać nowe ustawienie o nazwie:

Workflows.<nazwa_workflow>.OperationOptions

a w jej wartości wprowadzić tekst:

WithStatelessRunHistory

Zapisanie zmian spowoduje restart aplikacji, ale co tam – dzięki temu będzie widać co się działo z aplikacją!

Debugowanie aplikacji, czy skryptu z wykorzystaniem lokalnie instalowanych narzędzi to … przyjemność. Co jednak zrobić jeśli zdebugować trzeba nieco dziwne Logic Apps?

Oto propozycja.

1. Zacznij od przejścia na stronę https://webhook.site/
   Spowoduje to otwarcie strony oczekującej na tzw. webhook, czyli skierowane do tej strony żądanie POST. Teraz trzeba skonstruować to żądanie POST
2. W swojej aplikacji, w workflow dodaj nowy krok – akcję HTTP. Formatkę wypełnij w następujący sposób:
   • Metoda – POST
   • URI – wklej adres strony uzyskany w kroku nr 1
   • Body – skonstuuj jakiekolwiek tylko wyrażenie chcesz śledzić. Generalnie, to co tutaj napiszesz, za chwilę będziesz mógł zobaczyć na stronce z kroku nr 1
     
3. Zapisz zmiany i uruchom swoją aplikację. Kiedy workflow przejdzie do kroku z pkt. 2, to wywoła wskazany adres przekazując body zbudowane z aktualnej wartości zmiennych. Dzięki temu możesz zobaczyć, co tam się dzieje w środku aplikacji!
   

Funkcje, czyli z grubsza rzecz biorąc, główni reprezentanci linii serverless w Azure (FunctionApp i LogicApp) mogą łączyć się z siecią w trzech płaszczyznach:

• przez adres publiczny – jeśli aplikacja jest udostępniona publicznie
• przez private endpoint – co jest wykorzystywane do połączenia się do funkcji (klient chce skorzystać z funkcjonalności funkcji, więc łączy się do jej endpointa
• przez integration subnet – ten rodzaj połączenia jest wykorzystywany przez funkcję, kiedy chce ona „wyjść na zewnątrz”, np. w celu skorzystania z innych zasobów, które są potrzebne do działania tej funkcji.

Integration subnet nigdy nie jest wykorzystywane do połączenia się do funkcji. Nawet jeśli do integration subnet podłączysz NSG z regułami inbound, to zostaną one zignorowane, bo ruch przychodzący po prostu nie działa. Jedynym wyjątkiem są pakiety transferowane w ramach odpowiedzi na komunikację wychodzącą z funkcji, ale to zrozumiałe, bo bez tego komunikacja nie miałaby sensu.

Dzięki sprytnemu połączeniu ręcznie konfigurowanego routingu, NSG, integracji z Firewallem i innych mechanizmów konfiguracji sieci, administrator ma szeroki zakres możliwości definiowania jakie połączenia mogą być nawiązywane przez funkcje, np.: korzystanie z zasobów lokalnych sieci, połączenie do on-prem, połączenia z express route, innymi endpointami, wyjście do Internetu itd.

Do wykonania konfiguracji NSG może się przydać znajomość prywatnego adresu IP funkcji w integration subnet. Jest on zapisany w zmiennej środowiskowej WEBSITE_PRIVATE_IP.

Ruch sieciowy generowany przez funkcję podlega normalnym regułom. Jeśli np. chcesz przesłać pakiety do gateway’a, wystarczy odpowiednio zmodyfikować trasy routingu przypisane do podsieci.

Co ciekawe, application plan bazujący na windows, może się integrować z dwiema podsieciami, a na linux, tylko z jedną.

Sam routing to również ciekawa sprawa, bo można go konfigurować w trzech zakresach:

• Routing aplikacyjny – określa, co ma sie stać z ruchem generowanym przez działającą aplikację. Może sięgać tylko do zasobów lokalnych, albo wychodzić na zewnątrz
• Routing konfiguracyjny – określa, jak należy wykonywać routing przed uruchomieniem aplikacji, co jest wymagane np. do wykonania operacji pull image for container. Domyślnie komunikacja jest wykonywana przez połączenie publiczne, jeśli ma być inaczej, to wymagana jest zmiana. Jeśli funkcja ma sięgać do Key Vault po zapisane tam sekrety, które mają być np. używane w konfiguracji funkcji, to jeśli taka publiczna komunikacja jest zablokowana, to funkcja podejmuje próbę połączenia przez integration subnet
• Routing sieciowy – pozwala na zdefiniowanie konkretnych tras. Generalnie, ruch wychodzący z funkcji podlega wszystkim normalnym zasadom routingu, które przynajmniej częściowo można tutaj zdefiniować.

Z drugiej strony private endpoint, pozwala na połączenie się do usługi. Endpoint jest podłączony do wybranej podsieci, otrzymuje swój adres IP, a ten adres powinien być zarejestrowany w DNS. Dzięki temu wybrane usługi będą mogły połączyć się do funkcji i skorzystać z jej funkcjonalności.

Integrate your app with an Azure virtual network – Azure App Service | Microsoft Learn