ちりつもったー (original) (raw)

Windowsでもsudoでやっていきたい。

以前、GPOの制御下にあるPowerShellをadministratorで起動させるための手順を書きましたが……
hail-mary-log.hatenadiary.jp

こんな七面倒なことしなくても、gsudoというコマンドを開発してくれた親切な人が居ました。

やっぱりシェルに管理者権限でログインするよりも、ちゃんとコマンドで制御した方がセキュアですよね。
というわけで、早速導入してみましょう。

インストール手順

なんてことはなくwingetでインストールするだけです。
PowerShellは管理者権限で入ってください。

winget install gsudo 見つかりました gsudo [gerardog.gsudo] バージョン 2.5.1 このアプリケーションは所有者からライセンス供与されます。 Microsoft はサードパーティのパッケージに対して責任を負わず、ライセンスも付与しません。ダウンロード中 https://github.com/gerardog/gsudo/releases/download/v2.5.1/gsudo.setup.x64.msi ██████████████████████████████ 2.25 MB / 2.25 MB インストーラーハッシュが正常に検証されましたパッケージのインストールを開始しています... インストールが完了しました

ただwingetしただけではパスが通ってねえよ、と怒られます。

gsudo -v &: The term 'gsudo.exe' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

refreshenvでPATHを通して、再度動作確認をします。

使い方

bashやzshでのsudoとほぼ同じです。

wingetでインストールする時

gsudo winget git

管理者へのユーザー切り替えもできます。

gsudo

管理者切り替え時はウインドウのタブにAdministratorと表示される

exit

一般ユーザーに戻る

bashやzshで操作に慣れている身だと、やはりsudoに近しい方がしっくりきますよね。

サマリ

Steamのスクリーンショットの撮影方法と、撮影したスクリーンショットがどのように管理されているのかよくわかっていなかったので、調べたことをログとして残しておく。

スクリーンショットの撮影方法br

Steamで起動しているゲームはF12キーかコントローラの共有ボタンで撮影ができる。
このスクリーンショットはSteamのクライアントとしての機能での撮影であり、Windowsの標準として備わっている「Winキー+PrintScreenキー」での撮影とは異なってくる。

そのため、通常のWIndows標準機能としてのスクリーンショットとは画像の保存場所も異なってくる。

Steam上でのスクショの確認方法

Steamの機能で保存したスクリーンショットは、Steamクライアントから[表示]→[スクリーンショット]で確認できる。
またSteamでは撮影したスクリーンショットをSteamアカウントに付与されたクラウドストレージに保存することも可能。

スクリーンショットをエクスプローラーから開きたい場合は、フォルダのアイコンの「ディスクから開く」を選択する。

フォルダパス

で、このフォルダってどういうパターンで配置されているのか？という話になる。
] SteamをCドライブに通常通りにインストールしていれば、下記フォルダ内にゲーム毎にスクリーンショットが格納されている。
C:\Program Files (x86)\Steam\Steam\userdata\hogehoge\760\remote\なおhogehoge部分はユーザーIDの番号となっている

SteamのクライアントがインストールされているフォルダC:\Program Files (x86)\Steam\userdataの下に数字の羅列のフォルダがある。
この数字の羅列はユーザIDを示しており、ここがユーザーフォルダとなる。

ユーザーフォルダから更にremote以下までアクセスするとゲームごとのフォルダに辿り着くが、どういうわけか数字しか表記されていない。
これはSteam上でそのゲームを示すIDとなっている。
ここが保存したスクリーンショットをタイトルごとに格納しているフォルダとなる。

Steamのスクリーンショットの管理は基本的にクライアントから行えば良いが、まとめてコピペしたり削除したりする時は直接フォルダにアクセスできた方が捗るかもしれない。

サマリ

セットアップしたばかりのMacのターミナルを立ち上げたら、以下のような気持ち悪い具合にホスト名表記が変なことになっていた。
oreore@oreorenonotobukkukonpyuta ~ %
どういうこっちゃと思ったら、どうやらMacのホスト名がそのままターミナルでの名前表示になるようだ。

またコンピュータ名もこのような具合になっていた。

これでは見栄えが悪いので、今回はホスト名とコンピュータ名を変更していく。

MacでのPC表記について

MacOSで内部的にPCを定義する要素は3つある。

LocalHostName
ComputerName
HostName

Macにおいてコンピュータ名とホスト名、ローカルホスト名は異なる要素であることに留意。
ターミナル上での名前とネットワーク上でPCを特定するのはLocalHostName、GUI上のコンピュータ名はそのまんまComputerNameで定義される。
AD参加した場合はHostNameで定義される。

変更手順

[設定]→[一般]→[情報]から[コンピュータ名]のフィードを書きかけることで変更できるけれど、ここはターミナルからコマンドでサクッと変更していきたい。

MacOSにおいてホスト名などを操作するにはscutilコマンドを使用する。
scutil --get ComputerNameでコンピュータ名の確認
scutil --set ComputerName hogehogeでコンピュータ名をhogehogeに変更する。

まずはコンピュータ名の確認

oreore@kznonotobukkukonpyuta ~ % scutil --get ComputerName oreoreのノートブックコンピュータ

日本語表記とか気持ち悪いな。
というわけでComputerNameを変更していく。

oreore@oreorenonotobukkukonpyuta ~ % scutil --set ComputerName oreore-mac oreore@oreorenonotobukkukonpyuta ~ % scutil --get ComputerName oreore-mac

GUI上の[設定]から再確認しても、しっかり変更が同期されていた。

次にLocalHostNameを変更する。

oreore@oreorenonotobukkukonpyuta ~ % scutil --get LocalHostName oreorenonotobukkukonpyuta oreore@oreorenonotobukkukonpyuta ~ % scutil --set LocalHostName oreore oreore@oreorenonotobukkukonpyuta ~ % scutil --get LocalHostName oreore

ターミナルを再起動して、シェルの表記を確認。

oreore@oreore ~ % scutil --get LocalHostNmae oreore

以上！

サマリ

意外なことに、実はMacの標準機能として、クリップボードの履歴保存機能は搭載はされていなかった。
というわけでMacでも、WindowsでいうWin+Vと同じことを実行できるようにしていきます。

Macでクリップボード履歴を仕様するにはMaccyというソフトウェアが必要になる。GitHubはこちら。https://github.com/p0deje/Maccy/releases/tag/0.25.0

環境

Apple M3 Mac
Homebrew 4.3.10

導入手順

Homebrewでもインストールできるので、こっちの方が楽。

brew install --cask maccy

上記のインストールコマンドを打つと、大量のログが出る。
最後に🍺 maccy was successfully installed!と表示されれば文字通りインストール成功。

使い方

これがMaccyのランチャーアイコンとなる。クリップボードの履歴や表示するショートカットなどといった、細々とした設定はここで行う。

ちなみにwindowsと同じようにスクショをクリップボードにコピーする際は、通常のスクショ撮影+controlとなる。
例えば範囲指定なら、command+shift+4+controlという具合。
デフォルトの設定では履歴からクリップボードに移すときの動作がWin+Vと異なり、クリップボードに書き込むのみで、実際に入力フィールドに入力はされない。
そのため履歴から選択したあとペーストする必要がある。
ただ、これは設定「自動的に貼り付け」をオンにすることででWindowsと同様の動作にすることができる。
また、設定に「ログイン時に実行」するチェックボックスもあるので、常に使用する場合はこれを有効にしておく必要がある。

自分の設定は以下の通りこれでほぼほぼWindowsのクリップボード履歴に近い使い心地になった。

サマリ

Windows TerminalからPowerShellを管理者権限で起動する時、Windows Terminalのアイコンを右クリック→さらに「ターミナル」を右クリックして「管理者権限で開く」と手順を踏むのだけれども、毎度毎度これでは面倒なので自動化したい。

コマンドでの管理者昇格について

またコマンドでも管理者に昇格できるけど、これにも問題がある。
というのも、Start-Process powershell -verb runasで管理者になれるが、これはPowerShellを管理者権限で別プロセスを起動することになる。つまりもう1つPowerShellが開くことになって鬱陶しい。
その上、PowerShell7系で操作したにも拘わらずPowerShell5系が起動する。
Windows Terminalから起動しているPowerShell7系でもこれは同様。

環境

Windows11
なお今回の環境では職場などでAD管理でのGPOによってセキュリティが強化された環境を想定している。

Windowsターミナルの「設定」からプロファイルの「PowerShell」で「このプロファイルを管理者として実行する」という項目のトグルスイッチで設定できたという記憶があったのだけれども、どうやらGPOなどでのセキュリティ周りの設定によってはあったりなかったりする模様。

通常はこんな具合で「このプロファイルを管理者として実行する」という設定項目があるはず。
この設定項目があればオンにすればそれでOK。
今回はこの設定項目がGPOによって無効化されているケースの対処法となる。

作業手順

デスクトップショートカットから管理者権限のWindowsターミナルが立ち上がるショートカットを作成する。

デスクトップの空いたところで右クリック
新規→ショートカット
ショートカットのリンク先を下記に指定%LocalAppData%\Microsoft\WindowsApps\wt.exe
Windows Terminalとショートカットに名前をつける。

ちなみに、wt.exeは「Windows Terminal」の実行エイリアスファイルとなる。

次に作成したショートカットを常に管理者として実行するよう設定する。

ショートカットを右クリック→プロパティ
ショートカットタブ→詳細設定
管理者として実行にチェック→適用

あとはタスクバーにピン止めするなりなんなりよしなに。

アイコンが気に食わない

wt.exeへのショートカットアイコンがデフォルトのままなので、これだとどうにも据わりが悪い。

github.com

なので、こういうところから良い感じのアイコンをダウンロードしてくる。

タスクバーにピン止めしたwt.exeを右クリック→プロパティ→ショートカット→アイコンの変更。
ダウンロードしてきたアイコンに指定する。

これで良い感じ。

先日、Macを購入したことでThink pad X1 carbonは第一線を退くことになった。

hail-mary.hatenablog.com

windows11にアップグレードできないプロセッサなので、買取に出してお役御免になりそうだったけれど、二束三文な見積もりしか出なかったのでLinux入れて適当に遊んでいたほうが有益かなとも思えた。

というわけでどのディストリビューションにしましょうか。
Linuxってこういうふうに悩んでいる時が一番楽しいよね。その後は苦行だけど。

Think pad のスペック

2017年モデル
CPU:Core i7 7500U
メモリ:16GB
ストレージ:512GB
スペックそのものはまだまだやっていけるとは思う。
ただキーボードがペナペナというかぷにぷにしたというか、とにかく感触が気に食わないのが難点。

Ubuntu

飽きた。
新卒で入った職場では業務用PCにUbuntuをあてがわれたというなんともスパルタンな経験を得られたので、もういいかなーとも。
CentOSが潰えた今、サーバー用途としての需要が生まれたみたいですが、あんまり見たことない。

飽きたって言えるくらい触ってるなら、なんでLPICまだ受験してないんですか？ やめてくれカカシ、そのツッコミは俺に効く。

Linux Mint

こっちが安牌ですかね。Ubuntu系列なのでコマンドに関しては特に心配なし。
GUIがWindowsと似たようなレイアウトなのが無難なんか、すぐに飽きそうな感じがしなくもない。

Arch Linux

興味はある。色々と勉強になりそうだし。
ただ、本腰を入れた開発環境として使うとなると面倒を見るのがちょっと大変。
開発環境そのものもケアする必要があることを面倒とみるか、それも楽しみとか勉強の機会とみるか。
Linux Mintとこちらの二択になりそう。

Alter Linux

珍しい国産ディストリビューション。でも国産ディストリビューションってだいたい短命じゃないですか。
日本の学生が開発を行っているとのことで、気骨ある若者を応援する意味でも使ってみたいなとも思う一方で、いかんせん現役の学生さん中心ということで、ちょっと運営体制が気がかり。
ちゃんとマネタイズしておくれ。
とても良いものだというのはわかるのだけれども。
とりあずVirtualBoxとかHyper-Vとかで試してみるって流れで行ってみようと考えてる。

今回やらかしたこと

Chromeにはご存知の通り、閉じてしまったウインドウを復元できる機能があるが、この機能はChrome側が記録している直前に閉じたタブと一緒くたに8つまでカウントされている。
つまり、ウインドウを閉じた後、8つ以上のタブを閉じるとウインドウの復元はできなくなる。
誤って8つ以上削除してしまっても、タブならば履歴から遡れば復元できるが、ウインドウの場合はそうはいかない。
] というわけで、以下の具合な感じでやらかしてしまった。

Chromeを再起動した後に、復元されなかったウインドウがあった。
それに気づかないまま、10個近くタブを閉じた。
ウインドウを閉じたことに気づく。「履歴」→「最近閉じたタブ」からは、閉じたウインドウの「◯◯個のタブ」が無くなっていて、ウインドウを復元することができなくなっていた。

結論

「最近閉じたタブ」から消えたウインドウはどうやっても復元は無理だった。
Chromeの'History'ファイルから、DB Browser for SQlite から操作しても結局だめだった。

やってみた対処手順

Sessionフォルダをいじってみた

色々いじってみたところ、以下のフォルダに履歴データがあるのがわかった。

C:\Users\ユーザー名\AppData\Local\Google\Chrome\User Data\Default\Session

このフォルダにTabs_13365434289098641やSession_13365436209523866といったファイルがあった。
このファイルを別の箇所にバックアップして、再格納してみたけれど、状況は変わらず。

DB Browser for SQlite

Chromeの履歴まわりを管理しているHistoryファイルがSQliteで構成されているというので、DB Browser for SQliteでどうにか操作できないかと思って試してみた。sqlitebrowser.org

実行したクエリは以下

SELECT url, title, datetime(last_visit_time/1000000-11644473600, 'unixepoch', 'localtime') as last_visit FROM urls ORDER BY last_visit_time DESC LIMIT 50;

urlsテーブルからURL、タイトル、および最後に訪問した時間を取得し、訪問時間でソートして上位50件を表示するクエリとなる。
だけれども、ここで取得できる情報はあくまでURLのみなので、ウインドウの情報は取得できない。これはChromeの履歴データベースには、閲覧したURLやタイトルなどの情報が格納されているが、閉じたタブとウインドウの情報は明示的に保存されていないため。

ちなみに、これらの仕組みは同じChromiumエンジンを使ってるedgeも同様となる。

今後は対処していきましょう

今回、100近くのタブを一気に失うというやらかしをしてしまいましたので、今後はきっちり対処していきましょう。
対処法として有効なのは、このあたりのプラグインでしょうか。
いやone tabは既に導入していたのだけれども、使うのサボってたので、今後はこまめにまとめていくことにします。

chromewebstore.google.com