しばたテックブログ

気分で書いている技術ブログです。

PowerShell CoreのSnapパッケージが提供されました

既に各所で報じられ日本語情報も多いですが、思っていた以上にニュースになっている様なので本ブログでもとりあげてみます。

公式情報

細かい話についてはPowerShell Teamのこちらのブログエントリをご覧ください。

blogs.msdn.microsoft.com

Snapsについて

Snapsの公式サイトはコチラ。

snapcraft.io

Wikipediaによれば、

Snappyとはカノニカルが設計・開発したソフトウェアデプロイメントシステムかつパッケージ管理システムであり、元々はUbuntu Phoneオペレーティングシステム用に設計・開発された。
Snappyのパッケージは 'Snap' と呼ばれ、Snapを使うツールは 'Snapd' と呼ばれる。Snapは様々なLinuxディストリビューションで動作するので、ディストリビューションの上流のソフトウェアデプロイメントに依存しない。Snappyのシステムは携帯電話、クラウド、IoTやデスクトップパソコン向けに設計されている。

とあり、ディストリビューションに依存しない新しいパッケージマネージャーだそうです。

正直アーキテクチャなどでわからない部分は多いのですが、ざっと試した限りだとMicrosoft StoreとDesktop Bridgeの組み合わせに近い様に感じました。
(実際この例えが適切なのかは自信がありません...)

また、呼称について、今はSnappyでなくSnapsと呼ばれている?*1様です。
このあたりの事情については調べてみてもあまり情報を得ることができませんでした...

インストール方法

実際にSnapパッケージをインストールする手順を紹介します。

1. snapdのインストール

最初にsnapdをインストールする必要があります。

docs.snapcraft.io

に各ディストリビューション毎のインストール手順が紹介されています。
おおむね各パッケージマネージャーからのインストールに対応している様です。

今回はUbuntu 18.04の環境で動作確認をしたため、デフォルトでsnapdがインストール済みでありこの手順を行うことはありませんでした。

2. PowerShell Coreのインストール

Snapパッケージの管理はsnapコマンドから行います。
以下の様に--classicオプションを付けてsnap installコマンドを実行します。

# Stableバージョンのインストール
snap install powershell --classic

# Previewバージョンのインストール
snap install powershell-preview --classic

Ubuntu 18.04の環境で試すと下図の様になります。

f:id:stknohg:20180806163506p:plain

インストール時だけルート権限を要求されます。

f:id:stknohg:20180806163534p:plain

インストールが終わるとこんな感じです。

f:id:stknohg:20180806163556p:plain

現時点でUbuntu 18.04向けのdebパッケージが提供されていないPowerShell Core 6.0.3ですが、Snapパッケージであればこの様にインストール可能です。

f:id:stknohg:20180806163620p:plain

なお、--classicパラメーターを付けないとエラーとなります。

# --classic無しだとエラー
~$ snap install powershell
error: This revision of snap "powershell" was published using classic confinement and thus
       may perform arbitrary system changes outside of the security sandbox that snaps are usually
       confined to, which may put your system at risk.

       If you understand and want to proceed repeat the command including --classic.

この--classicパラメーターは、classic confinement policyと呼ばれる方式で公開されたアプリケーションをインストールするのに必要なパラメーターです。
Snapパッケージはデフォルトでファイルパスなどが分離された環境で動作する方式(strict confinement policy)となっているのですが、classic confinement policyではファイルシステムのルートが/になる等システム全体へのアクセスが許可されたモードになるそうです。
PowerShell Coreはシェルとしてシステム全体にアクセスする必要があるためclassic confinement policyで公開されています。

confinement policyについては

に詳しい説明があります。

従来のパッケージについて

最初のPowerShell Team Blogに記載されていますが、Snapパッケージが提供されたからといって従来のパッケージマネージャー向けのパッケージの提供を止めるといった事は無いそうです。
PowerShellを利用するための選択肢を増やし、利用者がより簡易にアプリケーションを管理できる様にするためのサポートといったところの様です。

設定情報など

最後に補足としてSnapパッケージとしてインストールされたPowerShell Coreの情報を幾つかか確認して終わりにします。

検証環境

先ほどと同じUbuntu 18.04の環境です。

パス情報

実行バイナリであるpwsh/snap/bin/pwshにありました。

~$ which pwsh
/snap/bin/pwsh

環境変数

PowerShell Coreを起動した後に見える環境変数には、以下の様にSNAP_で始まるSnapパッケージ情報を持つものが追加されています。

PS /> dir env:\SNAP*

Name                           Value
----                           -----
SNAP_USER_DATA                 /home/shiba/snap/powershell/7
SNAP                           /snap/powershell/7
SNAP_REEXEC
SNAP_NAME                      powershell
SNAP_VERSION                   6.0.3
SNAP_COOKIE                    HkSK6dTCpnVqHy4D9fY3WbPWwK1GdMmgC1rYHpnn076t
SNAP_ARCH                      amd64
SNAP_DATA                      /var/snap/powershell/7
SNAP_COMMON                    /var/snap/powershell/common
SNAP_CONTEXT                   HkSK6dTCpnVqHy4D9fY3WbPWwK1GdMmgC1rYHpnn076t
SNAP_REVISION                  7
SNAP_USER_COMMON               /home/shiba/snap/powershell/common
SNAP_LIBRARY_PATH              /var/lib/snapd/lib/gl:/var/lib/snapd/lib/gl32:/var/lib/snapd/void

PATH絡みの環境変数はこんな感じ。

PS /> $env:PATH -split ':'
/snap/powershell/7/opt/powershell
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin
/usr/games
/usr/local/games
/snap/bin

PS /> $env:PSModulePath -split ':'
/home/shiba/.local/share/powershell/Modules
/usr/local/share/powershell/Modules
/snap/powershell/7/opt/powershell/Modules

PowerShell Coreの実体は/snap/powershell/[パッケージのバージョン番号]/opt/配下にあり、モジュールパスは他のパッケージ版と同じになっています。

/snap/powershell/配下の構成

treeコマンドで/snap/powershell/配下を確認するとこんな感じでした。
必要なライブラリなどがバージョンごとに分離された環境にまとめられていることがわかります。

~$ sudo tree -d -L 5 /snap/powershell/
/snap/powershell/
├── 7
│   ├── etc
│   │   ├── gss
│   │   │   └── mech.d
│   │   └── ldap
│   ├── lib
│   │   └── x86_64-linux-gnu
│   ├── meta
│   │   └── gui
│   ├── opt
│   │   └── powershell
│   │       ├── Modules
│   │       │   ├── Microsoft.PowerShell.Archive
│   │       │   ├── Microsoft.PowerShell.Host
│   │       │   ├── Microsoft.PowerShell.Management
│   │       │   ├── Microsoft.PowerShell.Security
│   │       │   ├── Microsoft.PowerShell.Utility
│   │       │   ├── PSDesiredStateConfiguration
│   │       │   ├── PSReadLine
│   │       │   ├── PackageManagement
│   │       │   └── PowerShellGet
│   │       ├── en-US
│   │       │  
│   │      (├── ※ pwsh はココ)
│   │       │  
│   │       └── ref
│   ├── snap
│   │   └── gui
│   └── usr
│       ├── lib
│       │   ├── sasl2
│       │   └── x86_64-linux-gnu
│       │       ├── krb5
│       │       ├── openssl-1.0.0
│       │       └── sasl2
│       └── share
│           ├── doc
│           │   ├── libasn1-8-heimdal
│           │   
│           │   ・・・ (中略) ・・・
│           │   
│           │   └── zlib1g
│           ├── lintian
│           │   └── overrides
│           └── man
│               └── man5
└── current -> 7

*1:Snappyの呼称はSnappy Ubuntu Coreのディストリビューション全体を指すように推移している様に見受けられたのですがいまいちわかりませんでした。

保護されているパーティションをPowerShellで削除する

小ネタおよび備忘録です。

手持ちのESXiをインストールしたUSBメモリをフォーマットし直そうとした際に、GUIからだと先頭のブートパーティションが削除できなかったのが発端です。

Diskpartで削除する

最初に参考情報としてDiskpartで削除する手順を紹介します。

nasunoblog.blogspot.com

Insider MVPの那須さんのブログに手順が詳しく記載されています。

こちらのケースではEFIシステムパーティションですが、保護されているパーティションを削除する場合はDiskpartコマンドを起動して該当のパーティションを選択したのち、

delete partition override

overrideを付けてdelete partitionしてやればOKです。

PowerShellで削除する

ここからが本題です。

PowerShellでこの様なパーティションを削除する場合はRemove-Partitionを使います。
先述のoverrideパラメーターの様な特殊なパラメーター指定は必要ありません。

実例

今回は下図のディスクを例に挙げます。

f:id:stknohg:20180803111030p:plain

図のディスク2がESXiをインストールしていたUSBメモリで、先頭4MBがブートパーティションでGUIからは削除することができません。
(他にもいくつかパーティションがあったのですが、この図ではすでに削除済みです)

この4MBのパーティションをPowerShellを使って削除します。

1. 削除対象パーティンションの確認

はじめに管理者としてPowerShellを起動します。
Get-Diskコマンドを実行すると、システムから見えるディスクの一覧を取得できます。

Get-Disk

Get-Partitionコマンドでディスクにあるパーティションを取得できます。

Get-Partition -DiskNumber [該当ディスク番号]

f:id:stknohg:20180803111047p:plain

この例だと、DiskNumber = 2PartitionNumber = 1が対象のパーティションとなります。

2. パーティンションの削除

Get-Partitionコマンドの結果はWMIのMSFT_Partition*1クラスのオブジェクトであり、このオブジェクトをRemove-Partitionコマンドに引き渡すことでパーティションの削除ができます。

以下の様にパイプラインでつなげてやればOKです。

Get-Partition -DiskNumber [該当ディスク番号] -PartitionNumber [該当パーティション番号] | Remove-Partition

f:id:stknohg:20180803111059p:plain

パイプラインを使わず直接DiskNumber、PartitionNumberを指定しても構いません。

Remove-Partition -DiskNumber [該当ディスク番号] -PartitionNumber [該当パーティション番号]

3. 結果の確認

これで保護されているパーティションを削除できます。

f:id:stknohg:20180803111116p:plain

GUIから見ても確かに消えていることが確認できました。

*1:PowerShell上は Microsoft.Management.Infrastructure.CimInstance#ROOT/Microsoft/Windows/Storage/MSFT_Partition 型で表現される

無を取得

【2018.12.20追記】

転職しました。

blog.shibata.tech

【追記ここまで】

TL;DR;

いわゆる退職エントリ。
誰得ですが一度は書いてみたかったので。

無(職)を取得

新卒入社でだいたい15年くらい勤めた会社を今月末で退職して来月から無職になります。
先月末で事実上の最終出社を終えて今月いっぱい有休消化です。

社名を公表する気はありませんが*1、北海道内のSIerで従業員数が500~1000人くらいの規模感の会社に勤めていました。
皆さんがSIerに持っているイメージを想像してもらえば概ね該当するような会社です。

色々槍玉にあげられるSIerですが、駄目なところしかないのであれば10年以上も勤めるわけがなく、良いところもあれば悪いところもあるといった感じです。
あまり角の立つことも言いたくないので、まあ、「音楽性の違いにより脱退。」とだけ言っておきます。

次を決めずに辞めてしまったのは、実際には数年前から退職の機会をうかがっていたのですが、今年に入り大きめの案件と組織の変更があり、今回のタイミングを逃すとさらに数年単位で退職が困難になるのと、その間に激務でやられてしまう可能性が高かったためです。
あと、人生で一度くらい無職になってみたい、実績解除したいという気持ちもありました。

半ば逃亡に近い感じの退職*2ですが私の心は非常に晴れやかですっきりしております。

今後の予定

当初の予定では2~3カ月くらい静養と勉強の時間に充てて年末か来年から次の職場で働ける様な転職活動をしようと計画していました。
が、いざ退職届を出して無職確定となると「次が無い」という心理的なプレッシャーが思っていたより重くのしかかってきたので早めの転職活動をしつつ可能な限り無職生活を満喫しようと思っています。

ビジネス的な方向性

(厳密にはまだ辞めてませんが)前職では受託で道内企業の基幹業務システムを構築、運用する業務をやっていたのですが、いくつか自社サービスの運営もやっており、あまりビジネス的なこだわりは持っていません。

受託開発、サービス開発どちらでも面白そうな内容で無茶ぶりが無ければ積極的にやっていきたい感じです。

ただ、所謂SESについては距離を置きたいと考えています。

技術的な方向性

SIerというと一切コードを書かず技術要素が皆無というイメージが強いですが、前職はお世辞にも技術レベルが高いとは言えないものの自分らでコードも書きますし社員が技術要素に触れることのできる会社でした。

私自身はその中でも案件ごとの技術検証やインフラの構築と運用、社内開発環境の整備や社内フレームワークのメンテナンスなど行っており、社内でも特に技術寄りの立場にありました。

ただ、諸事情により所謂パブリッククラウドやHCIを扱うことが出来なかったため、これからは

  • AWS
  • Azure
  • Nutanix

あたりを扱うことのできる会社に行きたいなぁという漠然とした思いがあります。

残念ながらこれまで業務として扱っていないため現在の上記に対するスキルは低いです...
無職の間に学習していきたいというのが現状です。

今の技術スキル

職務経歴書をWEB上で公開しようか現在悩み中です。

とはいえ何も公開しないままだと得体の知れない無職のおっさんになってしまうので今の私にある技術スキルを公開します。
公開することで次の職につながる何かがあれば良いな、と、軽く考えております。

基本情報

プログラミングスキル

キャリアの長い順です。

  • VB全般 (VB6、VB.NET、VBA、VBScript)

    • VB6の時代から10年以上業務で扱っており、いちばん自然に書ける言語です。
    • VBA、VBScriptも書けます。
  • C#

    • 業務としては3年程度やっています。プライベートを含めればVBと同じくらいになります。
    • 基本VBを扱ってきたためキャリアとしてはそこまで長くないですが一般的な業務で要求されるレベルには達しているハズ。
  • PowerShell

    • 業務としては5年程度触れています。
    • PowerShellでMicrosoft MVPを受賞させてもらってますし「できる」といっても怒られないレベルにあると自負しています。
  • Python

    • 業務で2年程度触れていました。
    • 基本的な読み書きができ、小規模なアプリケーションを作れるレベルです。
    • Flaskを使った簡単なサイトの構築、独自のNagiosプラグインを作るのに利用しました。
  • Go

    • 業務で1年程度触れていました。
    • 基本的な読み書きができ、小規模なアプリケーションを作れるレベルです。
    • 独自のNagiosプラグインや簡単なCLIツールを作るのに利用しました。
  • Java

    • 他人が書いたコードの解析や簡単な改修ができるレベルです。
    • 基本的な読み書きはできますがあまり得意とは言えません。
  • COBOL

    • 業務で1年程度触れていました。
    • 基本的な読み書きができるレベルでしたが、最近は忘れつつあります...
    • WindowsでNetCOBOLという環境だったため所謂ホスト系の技術要素には疎いです。

他にもいくつかの言語に触れていますが、業務と絡めて列挙できるのはこのくらいです。
併せて以下のエントリもご覧ください。

RDBMS、ミドルウェアなど

こちらもキャリアの長い順です。

  • Oracle

    • Oracle 8i ~ 12c まで10年以上業務で扱っています。
    • Oracleのインストール、論理設計、物理設計、データベース構築、運用一通りのフェーズをこなせます。
    • 現在は失効済みですがOracle Master 10g Gold持ちでした。
    • 専任ではないもののDBAとしての業務経験もあります。
    • Windows RACの構築を何度かしています。
    • Oracle Database Applianceの構築を1度しています。
    • データベースの規模としては小~中規模程度(RAC 2~3ノード、容量数百GB程度)を扱えますが、大規模であったり要件の厳しいミッションクリティカルな環境の経験はありません。
  • SQL Server

    • SQL Server 2008 ~ 2016 まで5年程度扱っています。
    • SQL Serverのインストール、論理設計、物理設計、データベース構築、運用一通りのフェーズをこなせます。
    • データベースの規模としては単一インスタンスの小規模環境を多く扱ってきました。
  • PostgreSQL

    • PostgreSQL 9.2 の環境を1年程度運用したことがあります。
    • 基本的な運用ができるレベルです。
  • Citrix XenApp

    • MetaFrame 4.0、XenApp 5.0、XenApp 7.6を扱ったことがあります。
    • 小規模環境における設計とインストール、運用までを行えます。
    • XenDesktopの経験はありません。
    • 最近扱ってないため若干忘れつつあります。
  • CLUSTERPRO

    • Windows版を5年程度扱ったことがあります。
    • インストールおよび基本的な設定と運用ができます。
    • Oracleのクラスタリングのために利用しました。
  • NEC WebSAM JobCenter

    • Windows版を5年程度扱ったことがあります。
    • インストールおよび基本的な設定と運用ができます。
  • Nagios

    • Nagios Core 4系のインストールとカスタマイズを行い、自社サービスおよび顧客環境の監視基盤を構築し運用した経験があります。
    • 監視ホスト数十~百程度、監視サービス数百程度の小、中規模環境を扱ってきました。
  • HULFT

    • HULFT 6 ~ 7を取り扱った経験があります。
    • インストールと基本的な設定ができます。
  • JP1

    • 幾つかの受託案件で取り扱ったことがあります。
    • あまり詳しくないですが、基本的な概念を理解し運用できるレベルです。
  • GrapeCity製品全般

    • InputMan、SPREAD、MultiRow(すべてWindows Forms版)を使った開発を5年以上行ってきました。
    • ActiveReportsもバージョン6あたりからずっと扱っています。
  • Crystal Reports

    • Crystal Decisions社~Business Objects社の製品だった頃に扱ったことがあります。
    • 基本的な概念はまだ覚えていますが、だいぶ忘れつつあります...
  • SVF

    • Universal Connect/Xを使った帳票サーバーの構築経験があります。

インフラ、仮想化基盤

  • Windows Server

    • Windows 2000 Server ~ Windows Server 2016まで10年以上業務で扱っています。
    • サーバー台数にして数十台規模の企業内サーバーの設計と構築、運用ができるレベルです。
  • RHELおよびCentOS

    • RHEL 5系およびCentOS 6、7系を取り扱った経験があります。
    • サーバー台数にして10台程度までの小規模環境であれば構築、運用ができるレベルです。
    • 基本的な取り扱いができるレベルといえば良いでしょうか。
  • VMware vSphere

    • VMware vSphere 5系および6.0の構築および運用経験があります。
    • 小規模環境の構築のみで、基本的な概念は理解していますが個別の機能に精通するレベルではありません。
  • Hyper-V

    • Windows Server 2008 R2 ~ 2012 R2を親パーティションとする環境の構築および運用経験があります。
    • 小規模環境の構築が多く、簡単なHyper-Vレプリカの環境を構築できます。
  • NEC iStorage

    • エントリモデル(iStorage M300系程度まで)の設計と構築ができます。
    • 簡単な構成であればFC SANの構築経験もあります。

ここに記載していない技術要素の経験もありますがざっとこんな感じです。
インフラからアプリまで手広くやってきましたが、小・中規模のものが多く、広く浅くといった感じですね。

終わりに

意外と長くなってしまいましたが、こんな感じで無職の道を選びました。

ちょっと遅めの夏休みだと思い日々を楽しみつつ、なんとか生き延びて次のステップに進んでいきたい所存です。

*1:もし気になる奇特な方がいれば私に直接お尋ねください

*2:もちろん会社とは円満に話がついており、引き継ぎなどはきちんとやってます。あくまで言葉のアヤですので...