Testé depuis un media d’install de Catalina.
Connecter au réseau puis
sntp -sS pool.ntp.org
Testé depuis un media d’install de Catalina.
Connecter au réseau puis
sntp -sS pool.ntp.org
La mise à jour de DSM 6.x vers 7.x change un certain nombre de paramètres par défaut dnas la configuration de SMB.
Un article sur le site de Synology explique quelques causes/solutions possibles :
Mais dans mon cas tout ceci n’a pas réglé le problème.
La solution fut alors de se connecter en SSH (avec droits sudo) et de sauvegarder le fichier smb.conf puis de restaurer le fichier par défaut :
sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.BAK
sudo cp /etc.defaults/samba/smb.conf /etc/samba/smb.conf
puis de vider le cache SMB (Panneau de conf -> Service de fichiers -> Paramètres avancés) ce qui redémarre le service SMB. Les connexions ont alors refonctionné correctement.
En cas de suppression puis création de partition en milieu de disque, il peut arriver que les partitions ne soient plus numérotées dans l’ordre de leur positionnement sur le disque.
Bien que non gênante en fonctionnement, cette situation diminue la lisibilité du disque et augmente les risques de confusion lors de manipulations de partitions.
Pour remédier à ceci, on peut renuméroter les partitions dans leur ordre logique.
Pour les partitions MBR, il faut le faire à la main : on dumpe la table de partition, on la modifie, puis on la réécrit sur le disque.
dev=/dev/sdX
sudo sfdisk --dump ${dev} > sdX.bkp
nano sdX.bkp
# changer le chiffre
sudo sfdisk -f {dev} < sdX.bkp
# débrancher/rebrancher disque (ou reboot) pour forcer la relecture de la table de partition
Pour les partitions GPT, voir cet article
USB 2.0 : 480Mbps théorique, soit ~ 60Mo/s théorique (souvent 30-45 en réalité)
4 broches
USB 3.0 : 5Gbps théorique, mais 4Gpbs “théoriques réels” car codage 8b/10b, donc 500Mo/s théoriques (en pratique ~450 Mo/s)
9 broches
3.0 = 3.1 Gen 1 = 3.2 Gen 1x1 = SS = SS-5
3.1 = 3.1 Gen 2 = 3.2 Gen 2x1 = SS-10 ; 10Gbps théoriques
3.2 = 3.2 Gen 2x2 = SS-20 ; 20 Gbps théoriques
USB 4.0 = SS-40 ; 40Gbps théoriques ; n’existe qu’en USB-C.
On peut bien sûr mesurer les débits via un transfert de fichier, ou fio, mais on peut aussi constater directement le débit via lsusb. Pour ceci, il faut déjà identifier l’USB-ID d’un matériel ; par exemple avec un boitier SATA-USB3 Orico, un lsusb
nous donne :
Bus 003 Device 032: ID 152d:0576 JMicron Technology Corp. / JMicron USA Technology Corp. Gen1 SATA 6Gb/s Bridge
C’est donc l’identifiant 152d:0576
pour ce matériel. On le stocke :
usbid=152d:0576
On peut alors lancer lsusb -tv
pour avoir l’arbre USB détaillé. La vitesse théorique d’un périphérique est indiquée en fin de ligne. L’USB-ID du matériel étant indiqué à la ligne suivante, on peut filter avec grep en récupérant la ligne précédente ainsi :
lsusb -tv | grep ${usbid} -B 1
Si on veut tester différents branchements sans toucher au clavier, on peut lancer un monitoring automatique avec :
watch -n 0.5 "lsusb -tv | grep ${usbid} -B 1"
Il y’a plusieurs connecteurs, USB-A, USB-B, mini-B, micro-B, etc. Les câbles peuvent être équipés de différents nombres de broches en fonction de leur utilisation prévue (courant uniquement, wattage possible, courant + données, USB-2, USB-3 etc)
L’USB-C, au même titre que les autres, est simplement un format physique. Ses possibilités théoriques sont + étendues, mais non garanties. Il est possible d’avoir un câble C <-> C qui ne fasse que le transfert de courant sans données, ou bien qui ne fonctionne qu’en USB-2. Un connecteur USB-C peut également faire transiter des signaux non-USB (DisplayPort, HDMI, jack, électricité jusqu’à 240W).
Un cable USB-C possède (jusqu’à ?) 24 broches. Contrairement à l’USB-A, il ne me semble pas possible d’identifier visuellement le capacités d’un câble USB-C.
On peut également avoir des adaptateurs USB-C vers un autre format. Les capacités de ceux-ci dépendent également de leur conception. Il est possible d’avoir un adaptateur C <-> A qui soit limité à la vitesse USB2, voire qui ne fasse que le courant.
Dans le cas d’adaptateurs C <-> A en USB3, il est possible que les performances dépendent du sens d’insertion de l’USB-C. Dans mon expérience, pour bénéficier de l’USB-3, il faut que l’ensemble de la chaîne respecte le sens “classique”, à savoir la partie pleine du connecteur mâle vers le bas. Si on renverse un connecteur USB-C, alors le débit pourrait n’être que 480Mbps (USB2).
Je suppose que ceci dépendra de la conception des adaptateurs.
Selon la conception de la puce, il est possible que l’adaptateur soit vu même sans disque, ou bien qu’il nécessite le branchement d’un disque SATA pour être détecté. Penser à tester les 2.
But : avoir 2 installs Windows distinctes (en + d’une debian), chacune chiffrée par Veracypt, et que le choix se fasse via GRUB et sans avoir à choisir au sein de windows boot manager.
Si 2 installs Windows coexistent au sein d’une même ESP, alors ils partageront la même BCD, et comme le choix de l’OS intervient après le boot de l’OS et donc du déchiffrement Veracrypt, ça rend la solution non viable.
Solution (hacky) : avoir 2 ESP.
Structure du disque (table GPT) :
Démarche générale :
Installer Win1
Installer Debian
Vérifier le double-boot via GRUB
Installer Veracrypt sur Win1, chiffrer la partition système (ceci remplace notamment EFI\Microsoft\Boot\bootmgfw.efi par le lanceur de Veracrypt)
Vérifier le boot de Win1 chiffré en direct, puis via GRUB. Remettre GRUB en lanceur par défaut dans l’UEFI
Booter Debian, copier le code GRUB (section dans /boot/grub/grub.cfg
) de lancement de Win1 dans /etc/grub.d/40_custom pour être sûr de le conserver(on peut renommer l’entrée pour + de clarté)
Via efibootmgr
, supprimer les 2 entrées Veracrypt et Windows Boot Manager (essentiel pour éviter les conflits)
Via Gparted enlever le flag boot sur ESP1, le positionner sur ESP2
update-grub (il ne devrait plus avoir d’autre OS détécté par os-prober, seulement l’entré manuelle)
Installer Win2
Vérifier le triple-boot via GRUB
Installer Veracrypt sur Win2, chiffrer la partition système
Booter Debian, copier le code GRUB de lancement de Win2 dans /etc/grub.d/40_custom
Via efibootmgr
, supprimer les 2 entrées Veracrypt et Windows Boot Manager
Via Gparted enlever le flag boot sur ESP2, le positionner sur ESP1
update-grub
Normalement grub sera le seul OS référencé par l’EFI, il y’aura 1 entrée pour chacun des windows chiffrés, et chaque windows sera complètement indépendant d’un point de vue fichiers de démarrage.
On peut toutefois toujours monter la partition d’une install windows depuis l’autre en fonctionnement.
Dans le cas d’une synchronisation d’un AD local vers Azure Active Directory (AAD), il peut arriver d’avoir une incohérence dans les adresses mail d’un utilisateur entre l’AD local, le Office Admin Center (OAC) et le Exchange Admin Center (EAC).
Par exemple, supposons que
mondomaine.ville.entreprise.fr
. Ce domaine n’est pas routable sur internet. Nous avons en plus un domaine monentreprise.com
qui est routable sur internet et est le domaine utilisé pour les adresses mailmonentreprise.com
a bien été ajouté comme UPN dans le domaine localentreprise.onmicrosoft.com
chez Microsoft 365, et ajouté/validé le domaine monentreprise.com
sur M365Dans le cas où, en local, dans “Utilisateurs et Ordinateurs AD” (ADUC), le “Nom d’ouverture de session de l’utilisateur” (UPN) est “@mondomaine.ville.entreprise.fr”, alors l’utilisateur apparaîtra comme “@entreprise.onmicrosoft.com” dans l’OAC et dans l’EAC. Les mails envoyés arriveront via la même adresse “onmicrosoft”. L’adresse “@monentreprise.com” apparaît normalement comme un alias, et les mails envoyés à cette adresse sont bien reçus.
Si on modifie le nom d’ouverture de session en “@monentreprise.com”, après synchronisation (et délai de qqs minutes), l’adresse sera modifiée dans l’OAC.
Selon les cas, l’adresse peut également être modifiée dans l’EAC, mais pas systématiquement. Dans le cas où elle reste en “onmicrosoft”, c’est que l’attribut “mail” en local (ADUC) est manquant.
Si on ajoute l’attribut “mail” et lui donnant la valeur “@monentreprise.com”, après synchronisation (et délai), alors elle sera bien mise à jour dans l’EAC, et les mails envoyés auront l’adresse correcte.
Même procédure que pour buster avec quelques variations :
sudo aptitude install live-build live-tools
mkdir bookworm_live && cd bookworm_live
mkdir auto && cp /usr/share/doc/live-build/examples/auto/* ./auto/
Fichier auto/config
#!/bin/sh
set -e
lb config noauto \
--architectures 'amd64' \
--archive-areas 'main contrib non-free non-free-firmware' \
--bootappend-live 'boot=live config locales=fr_FR.UTF-8 keyboard-layouts=fr' \
--binary-images 'iso-hybrid' \
--distribution 'bookworm' \
--linux-flavours 'amd64' \
--source 'false' \
--backports 'true' \
"${@}"
Fichier config/package-lists/live.list.chroot
live-boot
live-config
live-config-systemd
systemd-sysv
#FIRMWARE
firmware-linux firmware-atheros firmware-b43-installer firmware-bnx2x firmware-brcm80211 firmware-iwlwifi firmware-libertas firmware-myricom firmware-netxen firmware-qlogic firmware-realtek broadcom-sta-dkms
#UTILS
nmap rcconf gparted hfsprogs ntfs-3g hfsplus hfsutils dosfstools lightdm bash-completion chntpw dcfldd bootlogd less mesa-utils numlockx ethtool grub2 ssh gdisk testdisk iftop nethogs pm-utils dmraid aptitude apt-file smartmontools debootstrap pciutils usbutils cifs-utils e2fsprogs mtools screen lvm2 net-tools mdadm lsscsi haveged rng-tools cryptsetup efibootmgr efivar ncdu wireless-tools dnsutils git iperf iperf3 lshw pmount grub-efi-ia32-bin grub-pc-bin grub-efi-amd64-bin curl dislocker
# TEAMVIEWER
libqt5webkit5 qml-module-qtquick2 qml-module-qtquick-controls qml-module-qtquick-dialogs
# DESKTOP
hplip system-config-printer xsane simple-scan mate-desktop-environment caja-open-terminal mesa-utils firefox-esr-l10n-fr chromium-l10n pulseaudio pavucontrol pavumeter mate-media-common mate-media mate-settings-daemon-dev mate-settings-daemon-common mate-settings-daemon chromium engrampa unrar pluma bluez blueman pulseaudio-module-bluetooth gddrescue ddrescueview vlc rdesktop conky network-manager-gnome webcamoid cheese webp-pixbuf-loader
Voir notes pour Bullseye
Si on héberge un WordPress derrière un reverse proxy (dans mon cas jwilder-nginx+letsencrypt) qui gère le https et les certificats, WordPress verra le trafic en non-chiffré.
Il faut donc l’informer que le trafic est chiffré de manière externe, et qu’il doit modifier les URLs en https://
.
Si je comprends bien, ceci se fait via la détection d’une en-tête définie par le reverse proxy.
Pour ceci, on ajoute dans le wp-config.php (dans le volume) :
//Load Balancer NGINX Proxy
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
$_SERVER['HTTPS']='on';
Install-Module ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName user@domain.com
Si le nom fourni est un admin, il pourra consulter les statistiques des autres boîtes mail.
Connection RPS (remote PowerShell) dépréciée :
Connect-ExchangeOnline -UseRPSSession
$mailbox = "user@domain.com"
(guillemets obligatoires)
Pour la taille de chaque dossier uniquement, sans les sous-dossiers :
Get-EXOMailboxFolderStatistics $mailbox | Select FolderPath,FolderSize,@{ name="FolderSizeBytes"; expression={((($_.FolderSize -replace '^(.*\()(.*)(\sbytes\))$','$2').Replace(',','')) -as [bigint])}}| Sort-Object -Property FolderSizeBytes -Descending | Out-String -Width 10000 | ft
Avec les sous-dossiers :
Get-EXOMailboxFolderStatistics $mailbox | Select FolderPath,FolderAndSubfolderSize,@{ name="FolderAndSubfolderSizeBytes"; expression={((($_.FolderAndSubfolderSize -replace '^(.*\()(.*)(\sbytes\))$','$2').Replace(',','')) -as [bigint])}}| Sort-Object -Property FolderAndSubfolderSizeBytes -Descending | Out-String -Width 10000 | ft
On peut le piper vers un fichier : > report.txt
Get-EXOMailboxStatistics $mailbox
Pour faire la correspondance entre les noms réels services Windows et leur nom d’affichage (localisés), on peut utiliser la commande Powershell
Get-Service
On peut également rechercher avec un motif du genre
Get-Service -Name *wua*
pour chercher sur le nom ou
Get-Service -DisplayName *update*
pour chercher sur le nom d’affichage. Aucune sensibilité à la casse.