著者:takahashi
Ubuntu 18.04で廃止されたgksuを使わずに、GUIアプリを管理者権限で実行する方法
Linuxに置いてのGUIアプリを管理者権限で起動する方法に”gksu”というコマンドを経由するという方法が以前はありました。
ターミナルからであれば非推奨ながらも “sudo -H” コマンドなどで起動できたのですが、例えばGNOMEなどから直接ショートカットで実行したい場合などでは、ターミナルが開かないためパスワードが入力できないという問題があります。
gksuコマンドではsudoと同じように権限の昇格を行ってくれる上、GUIのフロントエンドも表示してくれるので、ターミナルを経由せずに管理者権限でアプリやコマンドを実行させることが可能でした。
ところが、このgksuが本家debianのリポジトリから削除されたことに伴い、Ubuntu でも バージョン18.04で削除されてしまいました。
$ sudo apt install gksu
[sudo] hoge のパスワード:
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
パッケージ gksu は使用できませんが、別のパッケージから参照されます。
これは、パッケージが欠落しているか、廃止されたか、または別のソース
からのみ利用可能であることを意味します。
E: パッケージ 'gksu' にはインストール候補がありませんよって今後は、gksuコマンドを使ってGUI上から管理者権限でアプリを起動することができません。
これでは困ってしまうので、代替策をいろいろ調べたところ、下記記事を発見。
Linux Mint 19: 「’gksu’ not found」 廃止された gksu の代わりの方法 – 221B Baker Street
どうやら、代わりに”pkexec”コマンドを利用すればいいようです。
ただし、このコマンドをgksuのようにGUIで利用できるようにするには
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY コマンド
のようにする必要があるようです。
しかし、これを毎回打つのはかなり面倒なので、aliasへ登録しておきます。
上記の記事では
alias pkexec='pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY'
のようにpkexecを上書きすることをお勧めされていましたが、これだとオプション無しの”pkexec”コマンドが使えなくなってしまいますので、僕の場合はこのようにしました。
alias gksu='pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY'
こうしておけば、もはや存在しなくなったgksuコマンドでオプション付きのpkexecが呼び出せますし、新しいコマンドを覚える必要もないので便利です。
aliasの効果は一時的なので、永続化させるためにこの記述を、
~/.bashrcファイルの最終行あたりに追記しておきます。
こうすることで、ログインするたびに.bashrcに記述したaliasコマントが実行されるので、常に使用することが可能になります。
ただし.bashrcはGNOMEのようなデスクトップ環境から直接呼び出されないので、
(例えばショートカットを作成してダブルクリックだけで起動したい場合などで) GUIから直接aliasで作ったgksuコマンドをたたいても、先ほどのaliasが設定されていない為存在しないコマンドとなり実行できません。
そこで、先ほどのオプション付きpkexecコマンドをシェルスクリプトファイルに書き、パスが通っている場所(/usr/local/binなど)に置いて、普通のコマンドとして扱えるようにしてしまいます。
例えば、
vi /usr/local/bin/gksu
のようにして、次のように記述して保存します。
#!/bin/bash pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $1
こうすることで、gksu コマンド を実行したときに、コマンドが$1に渡されるので目的の動作をさせることができますし、パスが通ったディレクトリに置くことで、どのディレクトリからもコマンドとして実行できます。
つまり、GNOMEのようなデスクトップ環境上でも、直接自作の”gksu”コマンドが実行できるようになります。
gksuが使えなくてお困りの方は是非一度試してみてください。
著者:takahashi
WSLでWindows側のドライブをマウントする方法
Windows上でLinuxの環境を動作させることができるWindows Subsystem for Linuxですが、実は外部ドライブを接続した際、自動で認識してくれない仕様になっています。
恐らく、自動でマウントしてしまうと、取り外すときにややこしいことになる(安全な取り外しができなくなるなど)可能性があるのが理由なのだとは思いますが、そうは言ってもWSLから外付けドライブに直接アクセスしたいときももちろんあります。
実は、自動的にマウントはされないものの、デバイスを接続後にWSL上からコマンドでマウントを行うことが可能です。
Windows 10の「WSL」でネットワークドライブなどをマウントする – @IT
次のようにコマンドを入力します。
#(まだない場合は)マウント先のディレクトリを作成 mkdir -p ディレクトリのパス #作成したディレクトリに実際にデバイスをマウント mount -t drvfs デバイス名 マウントポイント(ディレクトリ名)
デバイス名は、マウントする対象のドライブ、マウントポイントはマウント先をそれぞれしていします。
例えば、Windows上の”E ドライブ “をWSLにマウントしたい場合、
mkdir -p /mnt/e #ない場合のみ
mount -t drvfs :E /mnt/eのようにすればマウントされ、WSL上では /mnt/e の中に外部ストレージの中身が入った状態になります。
外すときは
umount /mnt/e
でマウントを解除できます。
マウントの自動化などの詳しい操作方法は上記の参考サイトを参考にしてください。
著者:takahashi
Linux + bashシェルでランダムな文字(数字)列を生成する方法
初期パスワードやトークンなどの文字やテストでDBに入れて置く仮データなどを作るために、ランダムな文字列を生成したいときがあります。
最近ではそういった文字列を自動で生成してくれるWebサービスもありますが、大量に設定する必要がある場合全項目にコピペして入れていくのが大変なことがあり、そんな時はプログラム上で一気に生成して自動的に挿入させた方が便利な場合もあります。
今回はLinuxでシェルを使用している場合に便利な、ランダム文字列の生成方法をご紹介したいと思います。
・10文字のランダムな文字列を生成する
特殊文字を含めた10文字のランダムの文字列を生成します。
コマンドラインでランダムな10文字を得る方法 – Qiita
cat /dev/urandom | base64 | fold -w 10 | head -n 1
$ cat /dev/urandom | base64 | fold -w 10 | head -n 1
MNgyFRhl1r
$ cat /dev/urandom | base64 | fold -w 10 | head -n 1
MNgyFRhl1r
$ cat /dev/urandom | base64 | fold -w 10 | head -n 1
7RlziejIT/・ 0～32767の範囲で乱数を生成する
Bash限定ですが、0～32767の間の値をランダムに返してくれます。
数字しか受け付けない場合のランダムな値の生成に便利です。
echo $RANDOM
$ echo $RANDOM
8434
$ echo $RANDOM
210
$ echo $RANDOM
28360$RANDOMを呼び出すだけで乱数が生成できるなんで便利ですね。
シェル上で実行できるということは、これをシェルスクリプトに突っ込んでループさせたり変数的に利用したりできるので、いろいろ便利な使い方ができます。
ランダムな値が必要な時は、是非お試しあれ。
著者:takahashi
Linux上でSambaをGUIで設定する方法
2019/4/17追記:
肝心のsamba設定ツールのコマンドの名前が間違っていたため訂正いたしました。大変失礼いたしました。
Linux上でWindowsのファイル共有の仕組み(smb)を使ったファイル共有サーバーを構築することができるSambaですが、本家Windowsのファイル共有と比較した際の難点として、設定のしづらさがあります。
Linuxでは基本的に設定は特定のテキストファイルに記述することが多く、Sambaもこの方式になっています。
また、変更した設定ファイルの内容を適用させるには、sambaを一度再起動させる必要があります。
一方、本家のWindowsファイル共有は簡単に許可するユーザーを変えたり、フォルダ名を簡単に書き換えたりすることができる利点があり、設定が簡単で、初心者でも比較的扱いやすいのがメリットだったりします。(細かく権限を指定していくと面倒だったりしますが…)
…そう考えると、ちょっとSambaってめんどくさい…って感覚になってきますよね。
一応、デスクトップ環境としてGNOME系のものを搭載している環境であれば、Nautilusという(Windowsのエクスプローラーにあたる)アプリケーションからGUIでSambaを設定することができますが…
共有のON/OFFや書き込みの可能・不可能、ユーザーアカウント無しでのログインの設定のみしかできず、例えば”特定のユーザーにのみ許可をして、それ以外のユーザーのアクセスは拒否する”といったような設定ができません。
ということで、なんとか設定を簡単にできないかなぁと調べたところ、意外にも”詳細設定が可能な”GUIツールがありました。
system-config-samba
というツールです。
Ubuntuでは
sudo apt install system-config-samba
でインストールできます。
起動にはgksuが使えるユーザーアカウントでログイン中である必要があります。
起動するとこのような画面に。
現在Samba上で管理されている共有フォルダの一覧が表示されます。
メニューバー部分から
ワークグループの設定や
認証方法の設定
共有フォルダのパスや共有名の設定、
そして…
自分が一番欲しかったディレクトリごとのユーザー別の許可設定もちゃんとありました！！！
これはありがたい…
今後OSやSambaのアップデートによっては使えなくなる可能性もありますが、現状一通り設定が網羅されているようで使い勝手もバッチリです。
また、設定を変更するたびにsambaデーモンを再起動する必要もなさそうでした。
これでLinuxで構築するSambaもかなり使い勝手がよくなりそうです。
sambaの設定でお困りの方は試してみてください。
著者:takahashi
Ubuntuで最新カーネルにアップグレードするとVirtualBoxが動作しなくなった件
ふと社内のUbuntu 16.04で動作しているテストサーバーを再起動したところ…
仮想マシンが立ち上がらなくなってました。
最悪です…
このエラーメッセージが出てくる前に
sudo /sbin/vboxconfig
を実行すれば修復できる旨のメッセージが表示されたので実行しましたが、
# '/sbin/vboxconfig' vboxdrv.sh: Stopping VirtualBox services. vboxdrv.sh: Starting VirtualBox services. vboxdrv.sh: Building VirtualBox kernel modules. vboxdrv.sh: failed: Look at /var/log/vbox-setup.log to find out what went wrong.
となり、/var/log/vbox-setup.log を確認すると vboxdrv のビルドに失敗した、というメッセージ（コンパイルエラー）が出てました。
まずこのエラーで調べたところ、現在実行中のカーネルのカーネルへッダーが足りていないという情報を発見。
Ubuntu上でのVirtualBoxで仮想マシンを立ち上げようとしたときに Kernel driver not installed (rc=-1908) のエラーが出た場合の対処方法 – K-Lab
そういえばカーネルモジュール作るのにカーネルヘッダ必要だったなーと思い
sudo apt update sudo apt install linux-headers-$(uname -r)
を実行しましたが、
# sudo apt install linux-headers-$(uname -r)
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
linux-headers-4.4.0-143-generic はすでに最新バージョン (4.4.0-143.169) です。
linux-headers-4.4.0-143-generic は手動でインストールしたと設定されました。
以下のパッケージが自動でインストールされましたが、もう必要とされていません:
...
これを削除するには 'sudo apt autoremove' を利用してください。
アップグレード: 0 個、新規インストール: 0 個、削除: 0 個、保留: 18 個。あれ…既に入ってる…
もう一度
sudo /sbin/vboxconfigを実行してみるも当然通るはずもなく…
半分パニックになりながらいろいろ調べていたところ、Ubuntuのコミュニティサイト”Ask Ubuntu”の英語の記事でようやく有効な情報にたどり着きました。
VirtualBox error after last (Ubuntu) Software Update – Ask Ubuntu
どうやら、Ubuntu 16.04 に提供されている最新のカーネルをインストールすると、Virtualbox側が対応できていないためカーネルモジュールのビルドに失敗する…ということだそうです。マジかよ…
記事では VirtualBox 5.2.26でエラーが出たと書かれていますが、手元の環境では現時点で最新版の 6.0.4でも全く同じエラーが出ていたので、現時点でもまだ直っていないようです。
手元の環境ではカーネルバージョン 4.4.0-143 でエラーになっていましたが、記事によるとカーネルバージョン 4.4.0-138 であればVBoxがエラーにならず、かつ不具合等も出ず安定しているとのことだったので、このバージョンのカーネルより新しいものをすべて削除してしまうのが今回の解決策になりそうです。
とりあえず下記のコマンドを打ってカーネルをダウングレードします。
なお今回はOSの動作に必要なカーネルをいったんすべて削除するという大変リスキーな作業が含まれますので、十分注意してください。
※作業が完了するまで、絶対にOSを再起動しないでください。
カーネルのダウングレードを完了する前に再起動すると、最悪OSが起動しなくなります。
#問題を起こす新しいバージョンのLinuxカーネルを全て削除(この処理を行ったら必ず最後の処理まで完了させてください。さもないとOSが起動しなくなります。4.4.0-143よりも新しいカーネルがインストールされていれば、適宣削除対象に追加します。) sudo apt-get purge linux-image-generic linux-headers-generic sudo apt-get purge linux-image-4.4.0-139-generic linux-headers-4.4.0-139-generic \ linux-image-4.4.0-140-generic linux-headers-4.4.0-140-generic \ linux-image-4.4.0-141-generic linux-headers-4.4.0-141-generic \ linux-image-4.4.0-142-generic linux-headers-4.4.0-142-generic \ linux-image-4.4.0-143-generic linux-headers-4.4.0-143-generic #上記コマンド実行中に現在実行中のカーネルを削除しようとしている旨のメッセージが出ますが、はい を選択して削除してください。 #残骸のパッケージを削除 sudo apt-get autoremove #問題を引き起こさない古いカーネルをインストール(ダウングレード) sudo apt-get install linux-image-4.4.0-138-generic linux-image-extra-4.4.0-138-generic sudo apt-get install linux-headers-4.4.0-138 linux-headers-4.4.0-138-generic #再起動前までに必ずここまで完了させてください。
念のため目的のカーネルがインストールされているか確認します。
sudo dpkg --get-selections | grep image
$ sudo dpkg --get-selections | grep -e generic -e headers
libaccount-plugin-generic-oauth install
linux-headers-4.4.0-138 install
linux-headers-4.4.0-138-generic install
linux-image-4.4.0-134-generic deinstall
linux-image-4.4.0-137-generic deinstall
linux-image-4.4.0-138-generic install
linux-image-4.4.0-21-generic deinstall
linux-image-extra-4.4.0-134-generic deinstall
linux-image-extra-4.4.0-137-generic deinstall
linux-image-extra-4.4.0-138-generic install
linux-image-extra-4.4.0-21-generic deinstall
linux-modules-4.4.0-143-generic install
plainbox-provider-resource-generic installlinux-headers-4.4.0-138-generic と linux-image-4.4.0-138-generic、 linux-image-extra-4.4.0-138-generic のステータスが install となっていることを必ず確認します。
installとなっていれば再起動しても大丈夫です。
再起動が完了したら、次のコマンドを打って実行中のカーネルを確認します。
uname -r$ uname -r
4.4.0-138-genericとなっていれば作業完了です。
この状態で
sudo /sbin/vboxconfig
を実行すれば vboxdrv のエラーは解消しているはずです。
VirtualBoxの動作まで確認出来たら、問題が解決されるまでの当面の間、自動でカーネルがアップグレードされないようにaptパッケージマネージャーでカーネルバージョンを固定するように設定します。
sudo vi /etc/apt/preferences.d/linux-kernel.pref
などどして設定ファイルを作成し、下記の内容を書き込みます。
Package: linux-generic
Pin: version 4.4.0-138.164
Pin-Priority: 1001
Package: linux-headers-generic
Pin: version 4.4.0-138.164
Pin-Priority: 1001
Package: linux-image-generic
Pin: version 4.4.0-138.164
Pin-Priority: 1001これでaptでパッケージを更新してもカーネルは更新対象にならなくなります。
$ uname -r
4.4.0-138-generic
$ sudo apt update
ヒット:1 http://jp.archive.ubuntu.com/ubuntu xenial InRelease
取得:2 http://jp.archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB]
無視:3 http://dl.google.com/linux/chrome/deb stable InRelease
ヒット:4 http://archive.ubuntulinux.jp/ubuntu xenial InRelease
無視:5 http://archive.ubuntulinux.jp/ubuntu-ja-non-free xenial InRelease
取得:6 http://jp.archive.ubuntu.com/ubuntu xenial-backports InRelease [107 kB]
ヒット:7 http://archive.ubuntulinux.jp/ubuntu-ja-non-free xenial Release
取得:8 http://jp.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages [925 kB]
ヒット:9 http://dl.google.com/linux/chrome/deb stable Release
取得:11 http://jp.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages [807 kB]
取得:13 http://jp.archive.ubuntu.com/ubuntu xenial-updates/main amd64 DEP-11 Metadata [318 kB]
取得:14 http://jp.archive.ubuntu.com/ubuntu xenial-updates/main DEP-11 64x64 Icons [233 kB]
ヒット:15 http://ppa.launchpad.net/danielrichter2007/grub-customizer/ubuntu xenial InRelease
取得:16 http://jp.archive.ubuntu.com/ubuntu xenial-updates/universe amd64 Packages [739 kB]
取得:17 http://jp.archive.ubuntu.com/ubuntu xenial-updates/universe i386 Packages [677 kB]
取得:18 http://jp.archive.ubuntu.com/ubuntu xenial-updates/universe amd64 DEP-11 Metadata [252 kB]
取得:19 http://jp.archive.ubuntu.com/ubuntu xenial-updates/universe DEP-11 64x64 Icons [350 kB]
取得:20 http://jp.archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64 DEP-11 Metadata [5,964 B]
取得:21 http://jp.archive.ubuntu.com/ubuntu xenial-backports/main amd64 DEP-11 Metadata [3,324 B]
取得:22 http://jp.archive.ubuntu.com/ubuntu xenial-backports/universe amd64 DEP-11 Metadata [5,104 B]
ヒット:23 http://security.ubuntu.com/ubuntu xenial-security InRelease
4,531 kB を 1秒 で取得しました (3,831 kB/s)
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
アップグレードできるパッケージが 17 個あります。表示するには 'apt list --upgradable' を実行してください。
$ sudo apt list --upgradable
一覧表示... 完了
base-files/xenial-updates 9.4ubuntu4.8 amd64 [9.4ubuntu4.7 からアップグレード可]
distro-info-data/xenial-updates,xenial-updates 0.28ubuntu0.10 all [0.28ubuntu0.9 からアップグレード可]
google-chrome-stable/stable 73.0.3683.86-1 amd64 [72.0.3626.119-1 からアップグレード可]
libc-bin/xenial-updates 2.23-0ubuntu11 amd64 [2.23-0ubuntu10 からアップグレード可]
libc-dev-bin/xenial-updates 2.23-0ubuntu11 amd64 [2.23-0ubuntu10 からアップグレード可]
libc6/xenial-updates 2.23-0ubuntu11 amd64 [2.23-0ubuntu10 からアップグレード可]
libc6-dbg/xenial-updates 2.23-0ubuntu11 amd64 [2.23-0ubuntu10 からアップグレード可]
libc6-dev/xenial-updates 2.23-0ubuntu11 amd64 [2.23-0ubuntu10 からアップグレード可]
libpam-systemd/xenial-updates 229-4ubuntu21.17 amd64 [229-4ubuntu21.16 からアップグレード可]
libsystemd0/xenial-updates 229-4ubuntu21.17 amd64 [229-4ubuntu21.16 からアップグレード可]
libudev1/xenial-updates 229-4ubuntu21.17 amd64 [229-4ubuntu21.16 からアップグレード可]
locales/xenial-updates,xenial-updates 2.23-0ubuntu11 all [2.23-0ubuntu10 からアップグレード可]
multiarch-support/xenial-updates 2.23-0ubuntu11 amd64 [2.23-0ubuntu10 からアップグレード可]
snapd/xenial-updates 2.37.4 amd64 [2.34.2ubuntu0.1 からアップグレード可]
systemd/xenial-updates 229-4ubuntu21.17 amd64 [229-4ubuntu21.16 からアップグレード可]
systemd-sysv/xenial-updates 229-4ubuntu21.17 amd64 [229-4ubuntu21.16 からアップグレード可]
udev/xenial-updates 229-4ubuntu21.17 amd64 [229-4ubuntu21.16 からアップグレード可]なお、4.4.0-138-generic 以外のバージョンのカーネルを削除しても、まれにカーネルパッケージの残骸が残っていて、別のバージョンのカーネルがデフォルトで起動してしまうことがあるようです。
その場合は下記記事のような手順で起動時のブートローダ画面で 4.4.0-138 カーネルを指定して起動してください。
それにしても、再起動したらVirtualBoxが起動しなくなるとか本当に困るので、早く修正されてほしいですね…
著者:takahashi
Apacheのエラーページに出力されるバージョン情報を消す方法
フリーで利用でき、実質Linux上で動作するWebサーバーのデファクトスタンダードとなっているApacheですが、セットアップしてすぐの時によくやってしまうミスの一つとして、エラーページにバージョン情報を公開してしまう、ということがあります。
これはApacheのデフォルト設定が、ApacheのバージョンとOS名を表示するようになっているからです。
何がまずいのか、と思う方もいらっしゃるかもしれませんが、ApacheのバージョンやOSがわかる状態になっていると、もしそのバージョンに脆弱性が発見された際、攻撃者にヒントを与えてしまうことになります。
バージョンが見えてしまったからと言って必ず攻撃されるわけではありませんが、セキュリティ的にはよろしくないので、公開する環境においては非表示にすることが推奨されています。
ということで今回はエラーページからバージョン表示を無効化する方法をご紹介します。
なお、debian系OSとRedHat系OSで編集する設定ファイルが異なりますので注意が必要です。
debian系の場合
設定ファイルは
/etc/apache2/conf-available/security.confにあります。
このファイル中の25行目あたりに
ServerTokens OS
という項目がありますので
ServerTokens Prod
と変更しておきます。
この状態で
sudo service apache2 restart
とすれば反映されます。
RedHat系の場合
RedHat系の場合はデフォルトで設定ファイルに指定がないようなので
/etc/httpd/conf/httpd.confの末尾に一行書き足します。
ServerTokens Prod
書き足したら、下記コマンドを実行します。
sudo service httpd restart
これで設定は完了です。
この状態でサイトのエラーページを出してみると
このように、ApacheのバージョンとOSの表記を消した状態で表示されるようになります。
ApacheでWebサーバーを運用される方は是非参考にしてみてください。
著者:takahashi
音楽聞き放題Webサービス”PlayMusic”をデスクトップアプリ化してくれるアプリ”Google PlayMusicDesktopPlayer”
僕はGoogleのサービスを結構愛用しているのですが、それらのサービスの一つに、”GooglePlayMusic”があります。
これはGoogleが運営している所謂”音楽聞き放題サービス”なのですが、他のサービスと違う特徴として、自分が既にファイルとして所持している音楽ファイルもアップロードすることで再生リストに追加できる点があります。
元々はCDからコピーして自宅HDDに保存してシャッフル再生…という使い方をしていたので、PlayMusicはそんな僕のようなユーザーにもピッタリな音楽サービスとなっています。
そんなPlayMusicですが、欠点の一つとして”PC向けのプレイヤーアプリがない”点があります。
AndroidやiOS向けのアプリは他のサービス同様にあるのですが、PC向けの公式ネイティブアプリは同期専用のアプリ以外存在しません。
なのでPCからPlayMusicにアクセスするにはブラウザからアクセスする方法のみになります。
ただ音楽を聴くだけならいいのですが、ヘビィユーザーになってくると、ちょっと不便に感じる瞬間が出てきます。
システムとの相性が悪くてキーボートのホットキーで再生停止ができなかったり、ウインドウを開いていないと再生が止まってしまったり、OS統合機能の一部が利用できなかったりなどです。
やっぱりPlayMusicもネイティブアプリのような機能が使いたい…！という贅沢な悩みを解決してくれるアプリが、実はオープンソースで作られていました。
“Google Play Music Desktop Player“
というアプリです。
TweetDeckベースアプリのTweetenのような所謂”専用ブラウザ”系アプリで、 元々のPlayMusicの機能をアプリがオーバーライドすることで機能追加を実現しています。
Google Play Music Desktop Playerの場合も、立ち上げ直後は本家Webアプリと一見変わらなそうに見えますが、本家にはない便利な機能がいくつか追加されています。
例えば…
サイドメニューに、”Alarm”という機能が追加されています。
これをクリックすると…
こんな感じで、時間指定で音楽を流すことができる機能になっています。
他にも、
ミニプレイヤー機能や
ウインドウを閉じても再生を継続してくれる常駐機能もついています。
また、メニューのデスクトップ設定からアクセスできる
Playback APIを有効化すれば、Windowsのプレイヤー連係機能を利用して、再生中の曲をロック画面などに表示したり、他の機能と連携したりもできます。
また、PlayMusicに対してキーボードの”再生／停止”ホットキーが効かないPCも、このAPIを有効にすることで効くようになる場合もあるようです。
※Playback APIは一部セキュリティソフトを利用中の場合にブロックされてしまう場合があるようなので、注意してください。
こんな感じで Google Play Music Desktop Player にはネイティブプレーヤーアプリさながらの機能が利用できるので、ヘビィユーザーにとってはなかなかうれしい内容になっています。
何より、 Google Play Music Desktop Player はネイティブアプリとして扱われるので、
OS標準のランチャーにもちゃんとアプリのアイコン付きで追加できるのがうれしいですね。
Google Play MusicをPCで使われている皆さん、是非一度試してみてはいかがでしょうか。
著者:村上
【Linux】viエディタですべての行を削除する
若干遅ればせながら…明けましておめでとうございます。
皆様にとって、幸多き一年となりますよう心からお祈りいたします。
さて、新年の１記事目は、Linuxのテキストエディタ「vi」のコマンドについての備忘録です。
「:wq」や「:q!」など、定番のコマンドはすぐに覚えられるのですが、一行削除とか単語の検索とか、あまり使わないものに関してはほぼ毎回調べるので、いい加減にまとめ。
そもそも、vi 自体、あまり使わないので…未だに操作にもたつきます。
で、今回はあまり使わないかもしれない、すべての行の削除方法について。
といっても、決して難しいものではなく、コマンドモードで下記を実行するだけ。
:%d
コマンドモードとは、上記のような vi を実行できるモードです。
「Esc」キーを押せばコマンドモードに切り替わるので、挿入モードかコマンドモードか分からなくなったら、とりあえず Escキーを押しましょう。
ちなみに、1行だけ削除したい場合は dd と打ち込むとカーソルのある行が1行消えます。
これも便利ですね。
以上、viエディタでの行の削除方法でした。
未だに vi には若干の苦手意識がありますが…頑張ります。
著者:takahashi
【Linux CUI Tips】screenコマンドを使用時の入力や実行結果をログファイルに保存する方法
CUI上で長時間かかる処理を行わせて放置したい時や複数のターミナルを使い分けたいとき、SSHなどの接続が切れて処理が中断してしまうのが怖いときなどにscreenコマンドを使用すると非常に便利です。
このscreenコマンドですが、実はscreen内で出力された内容をファイルに保存する方法があるのをご存知でしょうか。
しかも、screenを使っていれば前準備無しでログの保存ができます。
ターミナル上で
screen
と入力し、screenに入ったら、
Ctrlキ+Aキー
を押したあと、すぐに
Shift+Hキー
を押します。
すると左下にメッセージが表示されます。
この状態になれば、ログが記録されるようになります。
停止する場合はもう一度
Ctrlキ+Aキー
を押した後に
Shift+Hキー
とすればログの記録は停止されます。
なお、ロギング中のscreenでログファイルを開いてしまうと無限ループしてログファイルの容量が一気に膨れ上がってしまうそうなので注意してください。
参考サイト:
ターミナルのログを自動保存したい – まちゅダイアリー
著者:takahashi
CentOS 7 でepelリポジトリのnpmでアップデートを行うとnpmが消されてしまう問題の回避方法
CentOS 7 の新環境を作り、epelリポジトリからyumでnpmをインストール。
sudo yum -y install epel-release sudo yum -y install npm
npmのバージョンを確認すると
3.10.10
と古かったため
sudo npm -g update npm
としたところ
- fstream-npm@1.2.0 node_modules/npm/node_modules/fstream-npm - normalize-git-url@3.0.2 node_modules/npm/node_modules/normalize-git-url - realize-package-specifier@3.0.3 node_modules/npm/node_modules/realize-package-specifier /usr/lib └── (empty) npm ERR! Linux 3.10.0-862.el7.x86_64 npm ERR! argv "/usr/bin/node" "/bin/npm" "-g" "update" "npm" npm ERR! node v6.14.3 npm ERR! npm v3.10.10 npm ERR! path /usr/lib/node_modules/npm/node_modules/fs-write-stream-atomic npm ERR! code EEXIST npm ERR! errno -17 npm ERR! syscall mkdir npm ERR! EEXIST: file already exists, mkdir '/usr/lib/node_modules/npm/node_modules/fs-write-stream-atomic' npm ERR! File exists: /usr/lib/node_modules/npm/node_modules/fs-write-stream-atomic npm ERR! Move it away, and try again. npm ERR! Please include the following file with any support request: npm ERR! /home/username/npm-debug.log npm ERR! code 1
のようなエラーが出てしまい、更新に失敗します。
そればかりか…
$ npm -v -bash: npm: コマンドが見つかりません $ which npm /usr/bin/which: no npm in (/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/username/.local/bin:/home/username/bin)
なんとnpm本体が消えてしまいました。
そんな馬鹿な…
流石にちょっと困ってしまったので、いろいろ調べたところ、npm公式のGitHubページのIssueでも同様の報告が上がっていました。
Try to update the npm cli and got an error #15821 – GitHub
内容を見ていくと、epelではなくnodejs公式のnodesourceというリポジトリを使用したら成功したという記述が。
半信半疑ながらも、nodesourceを使うことにしました。
とりあえず、一旦npmをアンインストールします。
sudo yum -y remove npm
$ sudo yum -y remove npm 読み込んだプラグイン:fastestmirror 依存性の解決をしています --> トランザクションの確認を実行しています。 ---> パッケージ npm.x86_64 1:3.10.10-1.6.14.3.1.el7 を 削除 --> 依存性の処理をしています: npm = 1:3.10.10-1.6.14.3.1.el7 のパッケージ: 1:nodejs-6.14.3-1.el7.x86_64 --> 依存性の処理をしています: npm = 1:3.10.10-1.6.14.3.1.el7 のパッケージ: 1:nodejs-6.14.3-1.el7.x86_64 --> トランザクションの確認を実行しています。 ---> パッケージ nodejs.x86_64 1:6.14.3-1.el7 を 削除 --> 依存性解決を終了しました。 依存性を解決しました ======================================================================================================================== Package アーキテクチャー バージョン リポジトリー 容量 ======================================================================================================================== 削除中: npm x86_64 1:3.10.10-1.6.14.3.1.el7 @epel 9.8 M 依存性関連での削除をします: nodejs x86_64 1:6.14.3-1.el7 @epel 16 M トランザクションの要約 ======================================================================================================================== 削除 1 パッケージ (+1 個の依存関係のパッケージ) インストール容量: 26 M Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction 削除中 : 1:npm-3.10.10-1.6.14.3.1.el7.x86_64 1/2 警告: ファイル /usr/lib/node_modules/npm/scripts/update-authors.sh: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/scripts/relocate.sh: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/scripts/release.sh: 削除に失敗しました: そのようなファイルやディレクトリはあり ません 警告: ファイル /usr/lib/node_modules/npm/scripts/publish-tag.js: 削除に失敗しました: そのようなファイルやディレクトリは ありません 警告: ファイル /usr/lib/node_modules/npm/scripts/maketest: 削除に失敗しました: そのようなファイルやディレクトリはありま せん 警告: ファイル /usr/lib/node_modules/npm/scripts/install.sh: 削除に失敗しました: そのようなファイルやディレクトリはあり ません 警告: ファイル /usr/lib/node_modules/npm/scripts/index-build.js: 削除に失敗しました: そのようなファイルやディレクトリは ありません 警告: ファイル /usr/lib/node_modules/npm/scripts/gen-changelog: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/scripts/doc-build.sh: 削除に失敗しました: そのようなファイルやディレクトリはあ りません 警告: ファイル /usr/lib/node_modules/npm/scripts/dev-dep-update: 削除に失敗しました: そのようなファイルやディレクトリは ありません 警告: ファイル /usr/lib/node_modules/npm/scripts/dep-update: 削除に失敗しました: そのようなファイルやディレクトリはあり ません 警告: ファイル /usr/lib/node_modules/npm/scripts/clean-old.sh: 削除に失敗しました: そのようなファイルやディレクトリはあ りません 警告: ファイル /usr/lib/node_modules/npm/scripts/changelog.js: 削除に失敗しました: そのようなファイルやディレクトリはあ りません 警告: ファイル /usr/lib/node_modules/npm/scripts: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/package.json: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules/realize-package-specifier: 削除に失敗しました: そのようなファイル やディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules/normalize-git-url: 削除に失敗しました: そのようなファイルやディレ クトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules/fstream-npm: 削除に失敗しました: そのようなファイルやディレクトリ はありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/write-file-atomic/package.json: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/write-file-atomic/index.js: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/write-file-atomic/README.md: 削除に失敗しました: そのよう なファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/write-file-atomic/LICENSE: 削除に失敗しました: そのような ファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/write-file-atomic: 削除に失敗しました: そのようなファイル やディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/wrappy/wrappy.js: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/wrappy/package.json: 削除に失敗しました: そのようなファイ ルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/wrappy/README.md: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/wrappy/LICENSE: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/wrappy: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/which.js: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/package.json: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/node_modules/isexe/windows.js: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/node_modules/isexe/package.json: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/node_modules/isexe/mode.js: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/node_modules/isexe/index.js: 削除に失敗しました: そ のようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/node_modules/isexe/access.js: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/node_modules/isexe/README.md: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/node_modules/isexe/LICENSE: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/node_modules/isexe/.npmignore: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/node_modules/isexe: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/node_modules: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/bin/which: 削除に失敗しました: そのようなファイルや ディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/bin: 削除に失敗しました: そのようなファイルやディレ クトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/README.md: 削除に失敗しました: そのようなファイルや ディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/LICENSE: 削除に失敗しました: そのようなファイルやデ ィレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which/CHANGELOG.md: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/which: 削除に失敗しました: そのようなファイルやディレクト リはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/validate-npm-package-name/package.json: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/validate-npm-package-name/node_modules/builtins/package.json: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/validate-npm-package-name/node_modules/builtins/builtins.json: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/validate-npm-package-name/node_modules/builtins/Readme.md: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/validate-npm-package-name/node_modules/builtins/History.md: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/validate-npm-package-name/node_modules/builtins/.travis.yml: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/validate-npm-package-name/node_modules/builtins: 削除に失 敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/validate-npm-package-name/node_modules: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/validate-npm-package-name/index.js: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/validate-npm-package-name/README.md: 削除に失敗しました: そのようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/validate-npm-package-name/LICENSE: 削除に失敗しました: そ のようなファイルやディレクトリはありません 警告: ファイル /usr/lib/node_modules/npm/node_modules.bundled/validate-npm-package-name/.npmignore: 削除に失敗しました: そのようなファイルやディレクトリはありません (省略)
大量の”ファイルが見つかりません”エラーが。
やっぱり本当に消えてしまってるようです…
アンインストールが完了したらnodesourceリポジトリをインストールします。
curl -sL https://rpm.nodesource.com/setup_8.x | sudo bash -
処理が完了したら、”npm”ではなく”nodejs”パッケージをインストールします。
sudo yum install -y nodejs
パッケージ名はnodejsですが、実際には同時にnpmもインストールされているため、インストールが完了すればnpmも使えます。
$ npm -v 6.4.1
バージョンも新しくなっています。
$ sudo npm -g update npm $ which npm /usr/bin/npm
アップデートも問題なく動作するようになったようです。
しかし、安定性の高いはずのepelリポジトリのnpmが致命的なバグを抱えたままになっているというのは…大丈夫なんでしょうか…