Zobrazují se příspěvky se štítkemdatacentrum. Zobrazit všechny příspěvky
Zobrazují se příspěvky se štítkemdatacentrum. Zobrazit všechny příspěvky

2021-01-10

Azure Site2Site VPN (ARM to Classic)

Issue:
Unable to get the new connection from classic to ARM VPN Gateway connected

Cause:
Authentication failure

Resolution:
Use the below commands to get the existing pre-shared key on the classic VPN gateway and then try to update the same on either sides.

Get-AzureVNetGatewayKey
   -VNetName <String>
   -LocalNetworkSiteName <String>
   [-Profile <AzureSMProfile>]
   [<CommonParameters>]

More Information:

PowerShell installation to use classic commands:

Install-Module -Name PowerShellGet -Force
Install-Module Azure
Install-Module Azure -AllowClobber
Import-Module Azure

Note:
While trying to use the classic subscription via PowerShell, you might have not seen the subscription listed from the below commands:

Add-AzureAccount
Get-AzureSubscription

To see your classic subscription here, you would have to add yourself as a co-administrator for the Classic Account which is what you did in this case.

Documentations for future references:

Azure Classic Select-AzureSubscription Error

No default subscription has been designated. Use Select-AzureSubscription -Default <subscriptionName> to set the default subscription.

Select-AzureSubscription : The subscription id doesn't exist.
Select-AzureSubscription : The subscription name doesn't exist.
Select-AzureSubscription : Parameter set cannot be resolved using the specified named parameters.

Add-AzureAccount : No subscriptions are associated with the logged in account in Azure Service Management (RDFE). This means that the logged in user is not an administrator or co-administrator for any account

Add-AzureAccount : AADSTS50074: Strong Authentication is required.

I had the following problems with Setting the default subscription because of two reasons. For this you need to have set co-administrator rights

Solution: Add classic administrator role inside AAD for user you are using to log in. Azure Portal > subscriptions > subscription - Access control (IAM) > Classic administrators > Add > Add co-administrator and try again!

Non responding Azure VM

It might happen to your virtual machine in Azure Cloud too. It gets stuck without responding to enabled services like SSH, HTTP even pings; in Microsoft words "VM was not responding to any means of communication".

Symptoms: There is no answer from the public IP range as same as from a private network from a machine on the same VNET and subnet. A tricky part is a machine in the portal looks up and running, stopping, and restarting. 

I opened the M$ support case because it was another occasion of the same behavior and I wanted to know the answer. We went through a classic scenario: Restart, deallocation, and redeploy via the portal. The extra task was the restart VM's from the serial console but the serial console did not come up even after a reboot.
Short answer: one of the disks was incorrectly mounted. One of the logs was containing crucial information as "Reached target Emergency Mode" followed by
Failed to mount /var/lib/docker. See 'systemctl status var-lib-docker.mount' for details. Dependency failed for Local File Systems.
That failed mount is preventing VM to boot, it needs to be fixed as described below. We had to create a rescue VM for which we used the OS disk of the impacted VM to create a new VM and it worked.

Solution: add to mount point /etc/fstab an item -nofail. Save and exit. Detach drive and do OS swap for the machine. The reboot should be OK and the machine should be online.

How to rescue the VM
  • Take the snapshot of OS disk - a full snapshot 
    • In disks – Created new disk using source path as a snapshot.
    • Verify the size of the disk and the type of disk used and used the same size and type to create a new disk.
  • Attach the disk to an existing Redhat VM, swap the disk, and mount it.
These few hints might help you to get rid of the troubles.

2020-07-15

Azure network peering when not authorized to access linked subscription

I got stacked for several hours on the case with network peering across different subscriptions with different tenantsRelated documentation. This scenario is usually when you do network peering with customer's Azure or between Azure with different owners. My case was easy since it was between Azure's managed by me, but still, there was a weird error. Luckily it got resolved by the way which you want to try too.

Azure Portal WebUI error message
Error: The client has permission to perform action 'Microsoft.Network/virtualNetworks/peer/action' on scope '<rg>/providers/Microsoft.Network/virtualNetworks/<vnet>/virtualNetworkPeerings/<peeringName>', however the current tenant 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' is not authorized to access linked subscription 'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy'.

That sounds like you are missing some access rights. I tried despite I was subscription owner in IAM configuration to add a minimal needed role "Network Contributor".
az role assignment create --assignee name.surmame@company.com --role "Network Contributor" --scope /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/<rg>/providers/Microsoft.Network/virtualNetworks/<vnet>

and also the same right for the other side
az role assignment create --assignee name.surmame@company.com --role "Network Contributor" --scope /subscriptions/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy/resourceGroups/<rg>/providers/Microsoft.Network/virtualNetworks/<vnet>

It should be now working, but it wasn't. The portal's authorize button in peering configuration opened a window where is usually a login page, but it stayed forever on redirection. URL was https://rc.portal.azure.com/tokenauthorize#access_token=XXX. Using different web browser was not enough to resolve.

What next? Let's try to use Azure CLI via Cloud shell console.
az network vnet peering create --name vnetPeeringName --resource-group rgName --vnet-name vnetName --remote-vnet-id /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/<rg>/providers/Microsoft.Network/virtualNetworks/<vnet> --allow-vnet-access

But an error out of this was the opposite subscription not found. So what next? WebUI is not working, the Azure command line is not working in this scenario? What's left? Yes, it's Powershell!
1) + 7)
Connect-AzAccount
Set-AzContext -SubscriptionId xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -TenantId zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz

2)
New-AzRoleAssignment -SignInName name.surmame@company.com -RoleDefinitionName "Network Contributor" -Scope /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/<rg>/providers/Microsoft.Network/virtualNetworks/<vnet>

8)
$vNetA=Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
Add-AzVirtualNetworkPeering -Name vnetPeeringName -VirtualNetwork $vNetA -RemoteVirtualNetworkId "/subscriptions/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy/resourceGroups/<rg2>/providers/Microsoft.Network/virtualNetworks/<vnet2>"


3) + 9)
Disconnect-AzAccount

4) + 10)
Connect-AzAccount
Set-AzContext -SubscriptionId yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy -TenantId qqqqqqqq-qqqq-qqqq-qqqq-qqqqqqqqqqqq

5)
New-AzRoleAssignment -SignInName name.surmame@company.com -RoleDefinitionName "Network Contributor" -Scope /subscriptions/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy/resourceGroups/<rg2>/providers/Microsoft.Network/virtualNetworks/<vnet2>

6)
Disconnect-AzAccount

11)
$vNetB=Get-AzVirtualNetwork -Name vnetName2 -ResourceGroupName rgName2
Add-AzVirtualNetworkPeering -Name vnetPeeringName2 -VirtualNetwork $vNetB -RemoteVirtualNetworkId "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/<rg>/providers/Microsoft.Network/virtualNetworks/<vnet>"

12)
Disconnect-AzAccount

Network peering is enstablished after this procedure and thing which I don't understand is why it works only in PowerShell console and not in both other options. Well, at least it's working now.

2020-04-29

az cli replace VMSS NSG

Let's show you some Azure Cloud settings change. It took me a while to make it work some you might appreciate it as a ready-made command(s).

If you don't like the existing network security group object linked with your virtual machine scale set, you can change it by using set command replacing value there with new id. There is no separate az vmss update command for it.

used variables:
  • $subscriptionId
  • $resourceGroup
  • $vmssName
  • $nsgNameNew
az cli command:
  • az vmss update --name $vmssName -g $resourceGroup --set virtualMachineProfile.networkProfile.networkInterfaceConfigurations[0].networkSecurityGroup.id=/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/networkSecurityGroups/$nsgNameNew
You need to refresh all nodes in VMSS before you can use that new NSG rules or delete old NSG object. You can do it by command
  • az vmss update-instances --instance-ids '*' --name $vmssName --resource-group $resourceGroup --output none --no-wait
or by portal =>  Virtual machine scale set => Scaling => Manual scale => Instance count => 0 and later increasing again. Deallocating VMSS is not enough.

I hope it helped.

2020-01-13

Azure App Gateway Certificate Invalid

Pokud se potýkáte s chybou při vytváření "HTTP Settings" při konfiguraci Azure Application Gateway, je možné, že jste se také nezamysleli nad tím, jaký otisk certifikátu do nějak nahráváte.

Pokud se detailně podíváte na podrobnosti chybové hlášky, uvidíte položku applicationGateways/trustedRootCertificates, jde tedy o potřebu nahrát tam soubor *.cer s kořenovým certifikátem, nikoliv certifikát doménového jména samotný. To vychází z principu, jakým aplikační brána funguje s šifrovanými spojeními, které na ni nejsou terminovány.

Jak tento certifikát získat? Pokud je již na nějakém Windows Serveru nainstalován, pak je třeba otevřít konzoli MMC, přidat Snap-in modul Certifikáty pro Local Computer, nalistovat Trusted Root Certification Autorities, najít ten odpovídající k danému certifikátu (k nalezení v Personal) a exportovat je pravým kliknutím (pod All Tasks) ve formátu Base-64 encoded X.509 (.CER). Celá konfigurace i s vizuálním doprovodem v nápovědě Azure.

Stále je také možnost použít "Use Well Known CA Certificate", pokud jde o skutečný certifikát. Tuto volbu samozřejmě není možné použít pro self signed certifikáty. 

2019-12-30

NAV Dynamics login error AAD

Error accessing Website Microsoft Dynamics NAV 2017 Web Client

Raw Url: /XYZ/WebClient/SignIn.aspx?ReturnUrl=%2fXYZ%2fWebClient%2f
Url: http://10.0.0.4:8080/XYZ/WebClient/SignIn.aspx?ReturnUrl=%2fXYZ%2fWebClient%2f
Type: Microsoft.Dynamics.Nav.Types.NavSecurityNegotiationException
Message: The Service Principal Name (Delegation) configuration has been set incorrectly. Server connect URL: "net.tcp://localhost:7346/XYZ/Service". SPN Identity: "DynamicsNAV/localhost:7346"
  • The X.509 certificate CN=*.domain.com, O=Company Ltd, L=City, C=CZ is not in the trusted people store.
  • The X.509 certificate CN=*.domain.com, O=Company Ltd, L=City, C=CZ chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. The revocation function was unable to check revocation because the revocation server was offline.
  • Restart service (I did it with a whole machine)
Solution

Go to IIS, open Application Pools, select the Microsoft Dynamics NAV2017 Web Client Application Pool, open Advanced Settings. Find Process Model / Load User Profile and make sure it is False (default is True). (source)

Other related errors and warnings:

This hint didn't help for solving: "The X.509 certificate is not in the trusted people store" to change certificate validation mode. (which config file?)

Background: there is a set Microsoft Azure Active Directory as Service Account for running NAV with deactivated MFA ($Sta = @() and Set-MsolUser -UserPrincipalName $serviceAccountFullName -StrongAuthenticationRequirements $Sta -State "MFA disabled for this user"). SPN is somehow not required for this scenario but it's still mentioned in many places...

setspn -l domain\computerName
    some SPN are registered
setspn -l domain\userAccount
    nothing registered
setspsn -A was unsucessful due to error Failed to assign SPN on account, error 0x2098/8344 -> Insufficient access rights to perform the operation even I had all rights - Global administrator

SPN Identity: DynamicsNAV was created inside Azure as Registrated App

2019-11-11

Jednoduchý proxy server s IPTABLES

Řešil jsem nutnost vytvoření super jednoduchého - jednoúčelového - proxy serveru, kvůli chybějícímu otevření firewallu a jak jinak než urgentnímu požadavku na zprovoznění mimo pracovní dobu.

Použil se na to virtuální stroj s Ubuntu a minimální velikostí. Jako proxy sloužil nástroj iptables, ale dalo by to udělat i s nginx proxy nebo apache2 proxy.

Prvnotní kontrolu prázdných iptables lze provést příkazem 
iptables-save
kde by nemělo být žádné pravidlo

Nejjednodušší je vytvoření skriptu s pravidlem transparentní proxy příkazem
nano natscript.sh

kam přijde text
#!/bin/sh
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -F
iptables -t nat -F
iptables -X
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination  10.10.10.10:8080
iptables -t nat -A POSTROUTING -p tcp -d 10.10.10.10 --dport 8080 -j SNAT --to-source 11.11.11.11


přičemž 10.10.10.10 je cílová adresa, kam se vlastně chceme připojit a 11.11.11.11 je adresa hostitelského serveru, aby se provoz dostal zpátky k odesilateli požadavku. Překlad portu neprobíhá a zůstává na 8080.

Pojďme na to a spustit skript, který založí vytvořená pravidla
sudo chmod +x natscript.sh
sudo ./natscript.sh

Po vykonání tohoto příkazu už bude vidět pravidlo v kontrolním logu s příkazem iptables-save

# Generated by iptables-save v1.6.1
*nat
:PREROUTING ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
:POSTROUTING ACCEPT
-A PREROUTING -p tcp -m tcp --dport 8080 -j DNAT --to-destination 10.10.10.10:8080
-A POSTROUTING -d 10.10.10.10/32 -p tcp -m tcp --dport 8080 -j SNAT --to-source 11.11.11.11
COMMIT
# Generated by iptables-save v1.6.1


Nyní je potřeba uložit tuto konfiguraci permanentně
sudo su root
sudo apt-get install iptables-persistent


případně při změně
recall dpkg-reconfigure iptables-persistent


Nicméně tato konfigurace stále nezůstane zachována při restartu serveru, je potřeba v souboru 
sudo nano /etc/sysctl.conf
odkomentovat řádek 
net.ipv4.ip_forward=1
a uložit

Namísto směřování požadavků na adresu 10.10.10.10:8080/path/file provádíte nyní dotazování adresy 11.11.11.11:8080/path/file se stejným výsledkem.

Pokud si přejete debugovat pravidla při překladu, doporučuji příkaz  tcpdump
sudo tcpdump dst port 8080 or src port 8080

To by bylo vytvoření jednoduchého proxy serveru obcházející chybějící ACL pravidlo na firewallu.

2019-08-19

Klonování Resource Group v Azure

Zadání bylo jednoduché, naklonujte resource group (něco jako složka ve které jsou součástky patřící k sobě v rámci nějakého projektu). První zádrhel je, že na to nemá webový Azure Resource Manager žádné klikátko - taková funkce v rozhraní chybí. Co s tím tedy?

Nejprve jsem našel skript Clone-AzureRMresourceGroup.ps1, který ovšem vyžaduje vypnutí původní infrastruktury, což je i v předprodukčním prostředí poněkud nechtěná vlastnost a nápad opustil.

Dalším pokusem bylo znovu zkopírování RG pomocí ARM template, kterou umí Azure RM ve webovém rozhraní snadno vyexportovat. Dokonce mnoho ostatních uživatelů jde touto cestou. Zádrhel je ve velikosti RG, kterou kopírujete. Jeden virtuální server s příslušenství asi jde, ale jakmile byl zahrnut Availability Set či Load Balancer, vytváří se ve schématech kruhové závislosti přes položku dependsOn a vůbec se konfigurační soubory nedají zrecyklovat pro nový i když identický deployment. 

Co se děje v template.json a parameters.json? Čekali byste, že všechno co se nastavuje bude v parameterech a v template jenom schéma, ale ono ne! Některé položky jsou po exportování v template natvrdo zapsané, typicky třeba lokalita, takže změnou parametrů se dostanou do schématu ještě větší zmatky. Další unikátní zdroje jako IP adresy či DNS názvy najdete v template.json také, což je samozřejmě špatně, pokud nevytváříte identickou RG znovu po smazání té předchozí, ale chcete klonovat.


Taktéž se mi celý template v jednom kuse nechtěl ani po úpravách nasadit do Azure, protože závislosti jako VM potřebuje IP, kterou chce NIC, ale NIC bez VM nejde apod. Řešením mohlo být vyexportovat jednotlivé šablony a hodnoty samostatně tak, jak byly vytvářeny chronologicky a to přes boční panel Deployments v RG.  Získal jsem tak 25x2 souborů, které bylo nutné ručně projít a zpracovat uvedené hodnoty, které měly navíc všelijaké nehomogenní identifikátory. Šlo by to u pár stupňové implementace, já se ztratil u 4. template z 25.

Takže zpátky k rýsovacími prknu. Dostal jsem povolení udělat odstávku běžících serverů a znovu použil výše zmíněný skript Jeffa Bowa, který asi za 20 minut vytvořil klon běžící RB bez nutnosti do toho nikterak více zasahovat a bez možnosti třeba přejmenovat zdroje v RG obsažené.

Pozor, po dokončení činnosti skriptu je potřeba zkontrolovat, zda-li se zkopírovalo všechno. Application gateway nebo SQL server se mi při použití skriptu nenaklonovaly. Taktéž chyběl diagnostický storage account, ale to zjevně nevadí.

Závěr? Buď si připravte velmi detailně ARM šablonu, zejména v případě, že budete RG vytvářet vícekrát nebo použijte script, ale počítejte s výpadkem.

Poznámka pod čarou: je těžké v česky psaném příspěvku hledat slova, tak aby nebyl text plný anglicismů, ale zároveň aby odborníci věděli o čem je řeč. Deploymnout je krásné, ale v obou jazycích špatně. Nadruhou stranu nad přepínáním a směrováním je třeba se pokaždé zamyslet, co je switching a co routing. Ale to jen tak na okraj...

2019-06-12

Zabbix agent installation

There are many good tutorials how to install Zabbix-agent to Ubuntu machine and how to interconnect it with Zabbix-server. I am adding some notes since I had troubles.

If you do
sudo apt-get install zabbix-agent
You can get error
zabbix-agent : Depends: libcurl4 (>= 7.16.2) but it is not installable
How to fix it?
sudo nano /etc/apt/sources.list
 and append to end following paragraph
###### Ubuntu Main Repos
deb http://us.archive.ubuntu.com/ubuntu/ bionic main universe 
deb-src http://us.archive.ubuntu.com/ubuntu/ bionic main universe 

###### Ubuntu Update Repos
deb http://us.archive.ubuntu.com/ubuntu/ bionic-security main universe 
deb http://us.archive.ubuntu.com/ubuntu/ bionic-updates main universe 
deb-src http://us.archive.ubuntu.com/ubuntu/ bionic-security main universe 
deb-src http://us.archive.ubuntu.com/ubuntu/ bionic-updates main universe 
After that just 
sudo apt-get update
It should be ready for install now, so do again
sudo apt-get install zabbix-agent
When it's done, you can configure zabbix agent by adding server address and match hostname name in WebUI and your agent machine. Don't forget to use encryption!
sudo nano /etc/zabbix/zabbix_agentd.conf
You need to restart the server after configuration
sudo systemctl restart zabbix-agent
If troubles continue check log file
cat /var/log/zabbix-agent/zabbix_agentd.log
Following error I received mostly when configuration was wrong. It helps to comment new modification and try to start the service again.
Job for zabbix-agent.service failed because the control process exited with error code. See "systemctl status zabbix-agent.service" and "journalctl -xe" for details.
invoke-rc.d: initscript zabbix-agent, action "start" failed.
OK, these are my notes if I need to install it and configure ever again.

If it doesn't help, just install older version
sudo apt-get install zabbix-agent=1:3.0.12+dfsg-1

2019-03-08

Používání SonarQube pro DevOps

Zprovozňoval jsem analytický nástroj SonarQube pro použití v Jenkins pipeline, nicméně jako standalone instanci tedy bez pluginu. K použití GetCodeflow s jehož autorem se znám jsem nedosal povolení od správce repozitáře, je potřeba tedy udělat analytiku lokálně. Kdybych náhodou instaloval nový server, píšu si následující poznámky.


Stažený instalátor SonarQube není instalátor. Složku je potřeba rozumně pojmenovat a někam permanentně umístit jako třeba C:\Program Files\sonarqube

Nejprve je nutné nainstalovat 64 bitovou Javu (JRE) a složku propojit s konfiguračním souborem C:\Program Files\sonarqube\conf\wrapper.conf, kam je třeba vložit řádek 
wrapper.java.command=C:\Program Files\Java\jre1.8.0_202\bin\java
Dále můžete vyzkoušet spuštění StartSonar.bat ze složky bin/windows-x86-64 přes command line (uvidíte případné chyby), pokud se načítá aplikace http://localhost:9000 (login admin/admin) je vše v pořádku. Kdyby byl větší problém, otevřete C:\Program Files\sonarqube\logs\sonar.log a koukněte na konec souboru co bylo příčinou pádu.
wrapper  | Waiting to start...
wrapper  | The SonarQube service was launched, but failed to start.
Před plným používáním je třeba doladit několik detailů. Zejména instalace samospouštěcí služby. Otevřete příkazový řádek v admin režimu, nalistujte C:\Program Files\sonarqube\bin\windows-x86-64\ a spusťte InstallNTService.bat, poté by se měla v systémových službách (services.msc) objevit služba SonarQube s automatickým startem.

V průběhu prvního testovacího buildu jsem se vinou obrovského solution (3 miliony řádku kódu ve 4,5 GB zdrojových kódů) potýkal s nedostatkem paměti, kterou bylo potřeba rozšířit. 32 bitová aplikace zvládá alokovat maximálně 2 GB paměti, proto je potřeba používat 64 bitovou. 
INFO: EXECUTION FAILURE
INFO: Final Memory: 15M/247M
ERROR: Error during SonarQube Scanner execution
ERROR: Java heap space
ERROR: The SonarQube Scanner did not complete successfully. Post-processing failed. Exit code: 1 
Nastavení se provádí v C:\Program Files\sonarqube\conf\sonar.properities. Hodnota sonar.web.javaOpts=-Xmx<číslo>m uvádí maximální možnou paměť a -Xms<číslo>m hodnotu při startu, rozpětí je tedy žádoucí velké.

Funkční nastavení: wrapper.conf
wrapper.java.additional.1=-Xms2048m
wrapper.java.additional.1=-Xmx%WRAPPER_SYSMEM_80.0%
Funkční nastavení: sonar.properties
sonar.web.javaOpts=-Xmx512m -Xms128m -XX:+HeapDumpOnOutOfMemoryError
sonar.ce.javaOpts=-Xmx8192m -Xms1024m -XX:+HeapDumpOnOutOfMemoryError
Jak vystavit SonarQube do sítě? Na mém serveru běží také IIS, takže je potřeba rezervovat adresu v IIS a nastavit redirect podle návodu. Pro samotné přepnutí aplikace pak stačilo nastavit DNS záznamy a uvnitř v aplikaci položku sonar.core.serverBaseURL => Administration/Server base URL. Navíc je potřeba zvýšit limit pro uploadované soubory, jinak končí analýza chybou "ERROR: Failed to upload report - HTTP code 404: "

Jak mít permamentní výsledky v databázi? Je potřeba C:\Program Files\sonarqube\conf\sonar.properities propojit s DB serverem a to následujícím způsobem. V DB (MSSQL) vytvořit databázi (v options zvolit Collation = Latin1_General_CS_AS), vytvořit uživatele, přiřadit mu db_owner právo a zrušit expiraci jeho hesla. (ideální je zkusit se připojit přes Microsoft SQL Server Management Studio). A vlastní konfigurace tedy
sonar.jdbc.username=sonarqube
sonar.jdbc.password=password

sonar.jdbc.url=jdbc:sqlserver://<IPorDNS>:1433;databaseName=sonarqube
A to je vše, restartovat službu SonarQube a nechat nástroj znovu načíst. Případné chyby jsou ve web.log.

Jak propojit přihlášení do rozhraní SonarQube přes Active Directory? Předně je třeba vytvořit uživatele (?) ve zmíněné doméně, který bude sloužit pro přístup samotného SonarQube. Konfigurace v sonar.properities je pak následující
sonar.security.realm=LDAP
sonar.security.savePassword=true
#sonar.security.localUsers=admin
ldap.url=ldap://DOMAIN.local:389
ldap.bindDn=sonarqube@DOMAIN.local
ldap.bindPassword=PASSinPLAINTEXT
#ldap.bindPassword={aes}passhashed
ldap.user.baseDn=cn=users,dc=DOMAIN,dc=local
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
ldap.group.baseDn=DC=inpulsetest,DC=local
ldap.group.request=(&(objectClass=group)(memberUid={uid}))
Není potřeba dalšího pluginu a přihlašování pak probíhá jen zadáním username bez domény. Pokud chcete mít z uživatelů administrátory, jde to snadno přes položku Administration/Security/Global permission a zaškrtnout příslušná oprávnění v sonar-users skupině.
 
Každopádně po této konfiguraci funguje nástroj v enterprise režimu a podporuje DevOps proces.

2018-11-23

Nastavení spouštění Jenkins úlohy na webhook z Gitu

Hrál jsem si s nastavováním automatického spouštění úlohy v Jenkins po commitu do GitHubu. Čistě teoreticky jde o triviální věc, kterou popisuje spousta videí, nicméně v praxi jsem narazil na několik problémů, které si tady odložím, abych to příště nemusel řešit. Třeba to pomůže i někomu dalšímu.

Na začátek hezké video, které popisuje úlohu bez nastavení tajného hesla:

Nejprve je třeba připravit Jenkins, předpokládám, že už vám joby a integrace s GitHubem funguje, jen pro informaci je třeba mít nainstalovaný plugin GitHubu.

Dále musí být dostupná adresa JENKINS_URL/github-webhook/ z veřejného internetu (nebo filtru podle GitHub IP adres), případně přenastavena na jinou v JENKINS_URL/configure sekce GitHub/Advanced (to druhé advanced) a políčko "Override Hook URL/Specify another hook URL for GitHub configuration" 

Manage webhooks zůstane nezaškrtnuto (sekce A.3) pro manuální instalaci webhooku na GitHubu.

Protože nechceme, aby každý, kdo se dostane k odkazu webhooku, spouštěl úlohu, je třeba nastavit heslo neboli "shared secret", respektive jej vytvořit v JENKINS_URL/credentials/add/secret text/system/ a pak nalinkovat "Shared secret". Nicméně je taky fajn to nejdříve vyzkoušet, že to funguje a secret přidat později (nezapomněout na to!).

Poté je třeba registrovat job, který se na webhook spustí. Zpátky na seznam úloh, rozklinout ho a možnost configure, pak checkbox GitHub project a do Project url vložit https://github.com/<user>/<repository>/ toto musí být uděláno manuálně.
Níže pak ještě zaškrtnout "GitHub hook trigger for GITScm polling", nebo to přidat do pipeline definice úlohy jako triggers{githubPush()}.

Poslední částí je nastavit URL webook na GitHubu, link: https://github.com/<user>/<repository>/settings/hooks/new, kde se vloží Payload URL: JENKINS_URL/github-webhook/ včetně lomítka na konci, content type jako application/json a secret je ten námi zvolený a uložený string.

Poté je výhodné udělat testovací ping a počkat na zelenou fajku, nicméně vlastní run jobu začně až po prvním commitu. Zejména na začátku nespěchtejte, občas to chce čas na reakci.