Accueil › Archive pour Système › Page 4

Système

Interroger une base PostGreSQL en PowerShell

Posté le de — Aucun commentaire ↓
Interroger une base PostGreSQL en PowerShell

Bonjour à tous, aujourd’hui on va intéresser aux bases SQL et PowerShell. Et plus exactement comment interroger une base PostGreSQL en PowerShell. Pour cela on va devoir s’y connecter, faire une requête, lire nos résultats en PowerShell et clore la connexion.

Je choisit volontairement PostGreSQL car (j’ai eu besoin de le faire a boulot, déjà) il nécessite que l’on installe au préalable le driver ODBC pour se connecter à la base. En effet si vous utiliser un serveur MSSQL, les dépendances nécessaires sont (en général) déjà livrées avec Windows.

Pour obtenir ce pilote vous pouvez vous connecter sur le site de PostGreSQL ici, télécharger puis installer le fichier MSI. Vous pouvez vérifier que celui ci est bien déployé en allant dans le panneau de configuration-Outils d’administration-Sources de données ODBC (32 ou 64 bits). Les connecteurs PostgreSQL UNICODE et ANSI devrait être présent.

A partir de là, on peut démarrer le code de notre module PowerShell. La première étape consiste à établir la connexion à la base. Et pour cela j’ai développé la Cmd-Let Get-PSSQLDBConnexion ci dessous :

Function Get-PSSQLDBConnexion{
    param(
        [Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()] [String] $Server,
        [Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()] [String] $Port,
        [Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()] [String] $DBName,
        [Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()] [String] $Username,
        [Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()] [SecureString] $Password
    )
… Lire la suite

Auto élévation de privilèges en PowerShell

Posté le de — 4 commentaires ↓
élévation de privilèges en PowerShell

Salut à tous, aujourd’hui on va s’intéresser au RunAs dans PowerShell, et plus particulièrement comment faire une élévation de privilèges en PowerShell. J’ai récemment eu besoin de distribuer un script à quelques utilisateurs, tous administrateur local de leur poste, pour qu’ils l’exécutent en tant qu’admin.

Je vous passe les détails, mais comme il n’y avait pas que des utilisateurs avancés en PowerShell, il me fallait un mode « clic-clic un peu propre » pour qu’ils lancent le script via un batch à la souris.

D’autant plus que le script jardine dans le registre et les fichiers système tout en utilisant des paramètres interactifs, en chemin relatif (puisqu’on ne sait pas où sur le poste nos utilisateurs vont exécuter le livrable). Et le tout sur des configuration de postes sécurisés qui ne me laissaient pas faire ce que je voulais via le traditionnel runas.exe.

Le diable est dans les détails… J’ai galéré un moment pour trouver un enchainement propre de mon .cmd et du .ps1, qui permet de s’affranchir des problématiques de chemin de fichiers, sans utiliser runas.exe.

Au final je m’en suis sortie comme ça.

Reconstruction du chemin dans le script CMD

C’est la partie la plus simple, vous … Lire la suite

Get-Date en "locals" US – PowerShell

Posté le de — Aucun commentaire ↓
Get-Date en "locals" US

Salut à tous, aujourd’hui une brève astuce dont on a eu besoin au boulot : comment sortir un Get-Date en « locals » US (ou une autre timezone, hein). En tout cas un local différent de celui de votre console. Exemple, si je saisi dans ma console :

(Get-Date).tostring("MMM d HH:mm:ss")
déc. 12 15:17:04

Je me retrouve avec un bel accent bien français sur « é » de « décembre ».

Sauf que parfois souvent, on a besoin que le format de sortie soit homogène entre différentes machines sur tout un parc. Par exemple, quand toutes ces machines parlent à un unique SIEM (au hasard… Splunk ?). C’est beaucoup plus simple si le timestamp arrive dans le même pattern quelque soient les sources.

Et donc, comment qu’on fait pour sortir un Get-Date en « locals » US ? Tout simplement, comme ça :

$LocaleUS = New-Object System.Globalization.CultureInfo("en-US")
(Get-Date).tostring("MMM d HH:mm:ss",$LocaleUS)
Dec 12 15:22:22 

Vous la voulez en UTC votre date, en plus ? Histoire que tout le monde parle dans le même référentiel ? Rien de plus simple :

$Timestamp = ((Get-Date).ToUniversalTime()).tostring("MMM d HH:mm:ss",$LocaleUS)
Dec 2 14:24:46

Et voilà, c’est tout bête, mais c’est bien pratique dès que vos scripts … Lire la suite

Tests des scripts PowerShell : arrêter de « Pester »

Posté le de — Aucun commentaire ↓
tests des scripts PowerShell

Salut à tous ! aujourd’hui on va se pencher à l’intégration continue en PowerShell et plus particulièrement les tests des scripts PowerShell avec le module PowerShell Pester.

Les tests ? on s’en fou… yolo, non?

Alors, non… les tests on s’en passe, certes, bien sur les petits SI, ou pour les bout de scripts en read-only à usage unique. Mais dès que vous commencez à vouloir maintenir votre code dans le temps… Les tests ça devient bel investissement, car si effectivement c’est pas passionnant à écrire, ils permettent quand même de spécifier clairement les entrées et les sorties attendus de vos scripts et donc de s’assurer que celles-ci ne seront pas modifiée lors de vos futures mise à jour.

Donc, pour répondre à la question : dois-je écrire un jeu de tests pour mon code ? j’aurais tendance à dire :

  1. Si votre code est destiné à avoir une durée de vie supérieure à quelques mois : oui.
  2. Sinon, c’est à évaluer en fonction de la « criticité » du script que vous comptez exécuter. Exemple : un script qui modifie 150 000 comptes utilisateurs de manière d’un côté, ou de l’autre côté celui test si le port
… Lire la suite