./gradlew installDebug # Installiert direkt auf das Gerät
# App neu installieren (überschreibt die vorherige Version)
adb install -r app/build/outputs/apk/debug/app-debug.apk
# App starten
adb shell am start -n com.example.helloworld/.MainActivity
# App stoppen
adb shell am force-stop com.example.helloworld
# App deinstallieren
adb uninstall com.example.helloworld
# Logs der App anzeigen
adb logcat | grep "HelloWorld"
# Screenshot vom Gerät machen
adb exec-out screencap -p > screenshot.pnggit fetch origin
git checkout feature/login
git rebase origin/main
git rebase -i origin/main
git push --force-with-leaseI encountered the same issue as well. Later, I checked my browser settings at chrome://settings/content and found that the settings had blocked local network requests for that site (Zugriff auf lokales Netzwerk). Subsequently, I changed the configuration to ‚allow‘, and then the problem was resolved.
$ fprintd-enroll
Using device /net/reactivated/Fprint/Device/0
Enrolling right-index-finger finger.
Enroll result: enroll-stage-passed
Enroll result: enroll-stage-passed
Enroll result: enroll-stage-passed
Enroll result: enroll-stage-passed
Enroll result: enroll-retry-scan
Enroll result: enroll-retry-scan
Enroll result: enroll-stage-passed
Enroll result: enroll-retry-scan
Enroll result: enroll-retry-scan
Enroll result: enroll-retry-scan
Enroll result: enroll-retry-scan
Enroll result: enroll-stage-passed
Enroll result: enroll-stage-passed
Enroll result: enroll-stage-passed
Enroll result: enroll-completed
sudo pam-auth-update
2️⃣ Häkchen setzen bei „Fingerprint authentication (fprintd)“.
3️⃣ Speichern → fertig.
find . -name 'Dockerfile' -exec sed -i 's/old\.azurecr\.io/new.azurecr.io/g' {} +tofu state list | grep '^kubernetes_' | xargs -n1 terraform state rmDer Unterschied liegt darin, dass dein AKS-Cluster und der Kubelet (Node-Pool) unterschiedliche Managed Identities haben!
🔹 1. aks.identity[0].principal_id → Cluster-Managed Identity (System-Assigned oder User-Assigned)
Wenn du in Terraform data.azurerm_kubernetes_cluster.aks.identity[0].principal_id nutzt, bekommst du die Managed Identity des AKS-Clusters selbst.
Wann wird diese Identity verwendet?
- Falls dein AKS-Cluster mit einer System-Assigned Identity oder einer User-Assigned Identity erstellt wurde.
- Wird oft für API-Calls oder Berechtigungen auf Subscription-/Resource-Group-Ebene genutzt.
- Diese ID wird genutzt, wenn du z. B. eine Azure Policy oder ein RBAC-Role Assignment für das AKS-Cluster machst.
💡 Beispiel:
data "azurerm_kubernetes_cluster" "aks" {
name = "aks-test"
resource_group_name = "aks-test"
}
output "aks_identity" {
value = data.azurerm_kubernetes_cluster.aks.identity[0].principal_id
}
Dieser Wert entspricht der „principalId“ des AKS-Clusters.
🔹 2. identityProfile.kubeletidentity.clientId → Kubelet-Managed Identity (Node Pool)
Die identityProfile.kubeletidentity.clientId, die du mit az aks show bekommst, gehört zur Kubelet-Managed Identity.
Wann wird diese Identity verwendet?
- Diese Managed Identity wird von den AKS-Knoten (Worker Nodes) genutzt.
- Sie wird verwendet, wenn die Nodes z. B. Azure Container Registry (ACR), Key Vault oder andere Azure-Ressourcen aufrufen.
- Falls du Azure Files oder Azure Disks als Volumes mountest, nutzt der Kubelet-Daemon diese Identity.
💡 Beispiel:
aks show --resource-group aks-test --name aks-test --query "identityProfile.kubeletidentity.clientId" --output tsv
Dieser Wert entspricht der „clientId“ der Kubelet Identity.
🔹 Unterschied in der Praxis
| Identity-Typ | Terraform (azurerm_kubernetes_cluster) | CLI (az aks show) | Verwendung |
|---|---|---|---|
| Cluster-Managed Identity | aks.identity[0].principal_id | identity.principalId | Wird für Azure-Ressourcen-Berechtigungen auf Cluster-Ebene genutzt |
| Kubelet-Managed Identity (Node Pool) | Nicht direkt abrufbar mit Terraform | identityProfile.kubeletidentity.clientId | Wird von Knoten für ACR, Key Vault, Azure Disks etc. genutzt |
🔹 Wie bekomme ich die Kubelet-Identity mit Terraform?
Aktuell bietet Terraform keine direkte Möglichkeit, die kubeletidentity.clientId aus identityProfile abzurufen.
Ein Workaround wäre, das CLI-Kommando mit data "external" oder local-exec auszuführen:
data "external" "kubelet_identity" {
program = ["bash", "-c", "az aks show --resource-group aks-test --name aks-test --query 'identityProfile.kubeletidentity.clientId' --output tsv"]
}
output "kubelet_identity" {
value = data.external.kubelet_identity.result["client_id"]
}
📌 Fazit
aks.identity[0].principal_idist die Managed Identity des Clusters.identityProfile.kubeletidentity.clientIdist die Managed Identity der Worker Nodes (Kubelet).- Terraform kann die Kubelet Identity aktuell nicht direkt abrufen – nur über
az aks show.
Möchtest du noch genauere Details zu deiner AKS-Konfiguration? 😊
4o
terraform state pull > backup.tfstateFalls etwas schiefgeht, kannst du den State mit terraform state push wiederherstellen.
Prozess (Pid) auflisten der auf das device zugreift:
$ fuser -u /home/tom/directory
/home/thomas/directory: 2435828(thomas)
$ ps -p 2435828
PID TTY TIME CMD
2435828 ? 00:00:01 nautilus
oder
$ lsof -l -w /home/thomas/directory
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nautilus 2435828 1000 27r DIR 0,95 4096 2 /home/thomas/directory (192.168.178.110:/LVM/directory)
Prozess killen der auf die device zugreift
fuser -km /home/thomas/directory- -k : Kill processes accessing the file.
- -m : Name specifies a file on a mounted file system or a block device that is mounted.