投稿

ラベル(Linux)が付いた投稿を表示しています

Mac の FTP クライアント

イメージ
macOS 用の FTP クライアントは他にもいくつかあるようだが、Linux でも共通して使えるので、 FileZilla にした。 Linux から macOS への設定データの移行は、Linux 側からエクスポートした FileZilla.xml を Mac 側の FileZilla でインポートするだけ。 .DS_Store を無視する .DS_Store を無視するためには、表示 > ディレクトリ リストのフィルタリングを開いて、フィルター ルールの編集を開き、Useless Explorer files の設定に .DS_Store を追加するとよい。 設定を追加したら、元の画面に戻って、左側のローカルフィルターの Useless Explorer files をオン(✅)にするだけ。これで一々、サーバーに .DS_Store をコピーして送ってしまうことに悩まされなくなる。

sudo のパスワード入力を省略できるようにする

OpenVPN で、接続確立後に自動で NFS をマウントし、接続切断時(直前)に NFS をアンマウントするシェルスクリプトを使おうと思った。ところが、mount / umount には root 権限が必要なので、通常では sudo するのにパスワード入力が求められてしまう。 色々調べた結果、/etc/sudoers という設定ファイルによって制御が可能であり、さらに sudoers を編集するのには危険が伴うので、visudo を通じて編集するのが常識的だということがわかった。 macOS / Linux のいずれにおいても、基本的には %admin ALL=(ALL) ALL となっている部分を %admin ALL=(ALL) NOPASSWD:ALL とすればよい。これは管理者グループに所属するユーザーを対象に、sudo コマンドの実行時にパスワードを不要とする設定である。(また、このようにグループの設定からアプローチするやり方ではなく、個々のユーザー単位で同様の設定をするアプローチでも可能である) 注 1:エントリーの順番 Mac では root と %admin しか元々エントリーがなかったので、気にする必要はなかったが、Linux(Ubuntu GNOME 16.04LTS)では root / %admin / %sudo となっていて、グループのエントリーが %admin と %sudo の 2 種類あった。この状態で %admin のエントリーを NOPASSWD にしても %sudo のエントリーで上書きされてしまうので、エントリーの順序を入れ替えて、%sudo の後に %admin のエントリーが来るように編集しなければならない。 注 2:Ubuntu GNOME 16.04LTS での管理者グループ ID Ubuntu GNOME 16.04LTS では管理者グループの ID が admin ではなく、 adm であった。にもかかわらず、sudoer のエントリーは %admin となっていたため、%adm と修正する必要があった。 注 3:visudo visudo はその名の通り、vi がベースになっているので、操作がよくわからない場合は vi の情報を調べてみるとよい。

VPN 環境の OpenVPN 化

イメージ
Mac をいじり出して、iCloud を軸にした標準アプリの設計思想が非常に気に入ってしまった。一般のユーザー視点なら無料 5GB で十分である。 ところが、Mac をメイン機とするならば、僕の場合、エンジニア(プログラマー)的側面も、一般ユーザーとしての立場に加えて必要になってくる。外にも持ち歩く MacBook に、開発中のデータが入っているのは非常にリスクが高いから、データの保管場所が MacBook の実機に依存するのは避けたい。だが、アプリを開発するためのプロジェクトファイルを iCloud ドライブにぶち込んでしまうと、どうやってもすぐに無料で利用できる 5GB の限界に達してしまう。かといって課金までして iCloud を増量したいとも思わない。 となると、せっかく実家で運用している QNAP 製の NAS があるので、それを使って iCloud のような運用ができないかと考えた。これまではデータを随時バックアップするという用途に NAS を使っていたのだが、クラウド的に、データ本体を常に NAS 側に置いておいて、それを端末側で参照するという形である。 ところが、写真などのマルテメディアデータはそのような専用のアプリが存在するのだが、ファイル一般となると iCloud ドライブのような使い方のできるオープンなアプリが存在しない。iCloud ドライブは macOS 専用だし、Google Drive にしても専用アプリをインストールする必要があり、それも Windows と macOS のみで Linux では使えない。 また、昔からある SMB の場合、LAN での利用を前提としていて、クラウドよりも一昔前のスタイルのまま停滞している感がある。 WebDAV 選択肢が限られていたので、まず最初に QNAP NAS で使える WebDAV を使ってみることにした。これは、macOS でも Linux でも標準で使えて、ネットワークドライブとして iCloud ドライブや Google Drive のようにアクセスが可能である。 ところが、WebDAV にはバグがあり、それは WebDAV が依存している apache のバグに由来するようだが、フォルダに index.html のファイルが存在すると、そのフォルダが空っぽ状態でファイル

Thunderbird (Linux) から Mail (macOS) へのデータの移行

イメージ
Thunderbird 同士であれば、Linux でも macOS でも(Windows でも)、基本的に Profiles ディレクトリ下にある XXX.default フォルダを移動すればいいので、データの移行に苦労することはない。 今回は、Linux から macOS の移行に伴って、メーラーも Thunderbird から macOS 標準の Mail アプリに乗り換えてみることにしたため、多少記録に値する点はあった。 まず、Linux から macOS には、Thunderbird の XXX.default を持ってくるだけでよい。macOS 側でわざわざ Thunderbird をインストールする必要はない。 次に、ここがネット上の情報では誰も触れていなかった点だが、Mail アプリで「ファイル > メールボックスを読み込む」によって XXX.default を読み込ませる時、Thunderbird 用のオプションが存在せず、「mboxフォーマットのファイル」を選ぶという点である。おそらく、Thuderbird 用のオプションがあったというのは古い情報なのだろう。 以上で問題なくデータの移行が完了した。

Samba

元の Linux マシンと MacBook の間でファイルを移動するために、Linux 側に Samba を導入した。Linux 黎明期から異 OS 間でのファイル共有で定番だった Samba だが、今でも代替が出てきておらず、第一線で使われているということを知って少し驚いた。 いくつか詰まった点としては、GUI で共有オプションなどを指定しても、何も機能せず、結局は /etc/samba/smb.conf を直接編集する必要があった。もしかしたらこれは権限の問題で、root 権限でログインしていたら、GUI でも直接操作できたのかもしれない。 また、Samba の設定でいくらパーミッションを設定しても、それが実際のファイルに付与されている権限を変更するわけではないので、あくまでも Samba で設定した権限の範囲内で、実際のファイルへそのファイルの権限に基いたアクセスが行われるという扱いのようである。 さらに、Samba を通じてアクセスするクライアント側で求められるユーザー認証は、Samba で独自に設定するユーザーとパスワードなのには注意する。Linux マシンにおけるユーザーアカウントとは関係がない。次のコマンドで設定する: sudo smbpasswd -a <user name>

旧 Ubuntu 機のデータを完全消去

Core 2 Duo のデスクトップ PC から、HP の Core i7 のノート PC に移行して 1 ヶ月以上が経過した。当初は、様子を見て、旧環境をそのまま放置しておいたのだが、どうやら新環境で問題はなさそうなので、旧マシンは処分することにする。 差し当たって、HDD のデータを完全消去しておく。「 Linuxを利用したHDDの完全消去 」を参考にした。よくまとまっていて、むしろ Live 環境の作成について字数が多くなり過ぎというくらいで、特に他に情報を参照する必要はなかった。 簡単にポイントをまとめておくと: Live 環境 スーパーユーザー化 デバイスファイル名の調査 shred コマンド で、デバイスファイル名自体は除くとして、su や shred の各コマンドのオプションもそのまま使えるものだった。 Live 環境は、色々なやり方があり、僕の場合、UNetbootin を使った Live USB を作成した(ISO イメージは Ubuntu GNOME のものを使った)。

DBP: Ubuntu 用 Gimp 自動化プラグイン

Gimp で処理を自動化して複数の画像ファイルを処理するために、Script-Fu や Python-Fu がデフォルトで用意されている。Lisp や Python をスラスラ操れる人ならいいのだけど、僕の場合、Java や Perl が「ネイティブに」操れる言語で、Lisp や Python の方はリファレンスを駆使しないと、ちょっと厳しい。 それほど大げさな処理をするのではなくて、一律、サイズを変更したり、画像を回転させる程度の決まりきったことをしたいだけ。こういう時に便利な Gimp 用プラグインが、 David's Batch Processor (DBP) 。おそらく Ubuntu (Linux) 用で、公式ページに説明されている通りのインストール手順に従って、make すると、インストールできる。 やりたい操作が、GUI の形で行えるので、とても使い易い。

QNAP の Apache で .htaccess を有効化

QNAP の Apache では、.htaccess がデフォルトでは無効化されているので、有効にするには、apache.conf の設定を 1 ヶ所、変更する必要があります。 <Directory /> Options FollowSymLinks - AllowOverride None + AllowOverride All Order deny,allow Deny from all </Directory> apache.conf は /etc/config/apache/apache.conf にあります。vi を使って編集してもいいですが、僕の場合は、scp を使ってローカルにコピーし、gedit で編集して、scp でアップロードして戻すやり方で作業しています。

Ubuntu (Linux) と QNAP (NAS) 間で rsync - その 3 / 3

rsync は SSH 越しでも行えるので、QNAP の SSH サーバーをセットアップすれば、「VPN を経由した NFS による rsync」(👉 その 2 )という少々器用な真似をせずに済むようになる。 ※ただし、QNAP の SSH は admin しかログインできない点には留意する。以下の作業ではすべて、admin で SSH 接続するためのものである。 QNAP の SSH 環境を整備する 自機側で RSA キーペアを作成する。 ssh-keygen -t rsa -C " 作成するキーペアに関するコメント情報 " 作成したキーペアのうち、公開鍵(id_rsa.pub)の方を QNAP (NAS) へ scp コマンドで転送する。当然、この際は、QNAP 側の SSH サービスはオンにしておく必要があり、admin アカウントとパスワード認証で scp の処理を実行することになる。 scp ~/.ssh/id_rsa.pub admin@ (NAS IP Address) :~ (admin にとっての ~ へコピー) SSH で QNAP に admin でログインし、~/id_rsa.pub を ~/.ssh/authorized_keys へ(追記)コピーする cat id_rsa.pub >> .ssh/authorized_keys chmod 600 .ssh/authorized_keys rm id_rsa.pub 以上で、QNAP 側の準備は終わり。 SSH から一旦ログアウトし、再び SSH で QNAP にログインすると、(自機側によって)パスフレーズを尋ねられる。問題なければ、ログインに成功する。これでパスワード認証ではなく、公開鍵認証によるログインができるようになった。 ※自機にある作成したキーペアはちゃんと管理しておくこと(セキュリティ面と、バックアップ面の両面において) 一応、SSH を利用するための作業としては以上である。SSH というのは、公開鍵をサーバー側にアップロードしておいて(公開鍵をアップロードできるのは、本人であるという前提による)、その公開鍵(サーバー側)と暗号鍵(本人側)をペアで使って、本人認証を行うというのが基本コンセプト。 ただし

Ubuntu (Linux) と QNAP (NAS) 間で rsync - その 2 / 3

イメージ
👉 その 1 では主に rsync コマンドの記述について説明したので、ネットワーク経由で NAS の指定した path にバックアップする方法の詳細については述べなかった。今回からは、その部分について、僕が試行した方法について説明する。 NAS の特定のフォルダを、NFS を使って自機にマウントして、自機のフォルダとして利用する まず最初に僕がやったのが、NFS を使って自機にマウントして、自機のフォルダと見做せるようにし、rsync では、ローカルのフォルダー間での同期として扱うやり方である。この場合、rsync の dest_path の指定において、NAS のネットワークアドレスに関する(admin@XXX.XXX.XXX.XXX: の部分の)記述は不要となり、次のような形で済む: rsync -auv --delete --progress ~/mydata /mnt/qnap/backup Linux(UNIX 系 OS)の非常に優れた文化が、このように、ネットワークドライブであろうが、さらには、入出力デバイスであろうが、すべて「ファイル」としてアクセスできるように、スッキリと極めてスマートに整えられている所である。 それはいいとして、この場合、rsync 側では、ネットワークのことは意識する必要はなくなるものの、NFS を使ってマウントする際には、ネットワークアドレスを指定する必要があるので、実質的には違いはない。誰が請け負うかが変わっただけである。 1: QNAP 側 で NFS を設定する QNAP 側では、「権限 > 共有フォルダ > NFS ホストのアクセス」で homes を「アクセス権:制限なし」にする。 2: Ubuntu 側で NFS を設定する まず、NFS をインストールする: apt-get install nfs-common NAS の共有フォルダを、Ubuntu 側に NFS としてマウント: マウント用ディレクトリを用意: mkdir /mnt/qnap マウントする: mount -t nfs XXX.XXX.XXX.XXX :/homes/ username /mnt/qnap (参考: How To Set Up an NFS Mount on

Ubuntu (Linux) と QNAP (NAS) 間で rsync - その 1 / 3

実家に設置している QNAP 製の NAS に、自機(Ubuntu)からデータを rsync でバックアップする体制を確立する。 rsync は、最初に一度バックアップしてしまえば、以降は差分(変更したもの)だけを修正する形になるので、毎回全体を丸ごとバックアップするような重い作業とはならず、極めてスマート。 rsync コマンドの使い方 rsync コマンドは、man rsync すれば詳細は調べられるとして、自分にとって必要な形は次の通り: rsync -auv --delete --progress src_folder dest_path -a はアーカイブ用オプションで、ファイルの権限情報の保持などのいくつかのオプションのセット指定。-u は、タイムスタンプが新しくなる場合にのみ更新する。-v --progress は詳細な情報を作業の進行とともに表示。--delete は、削除したファイルも同期して削除する。 src_folder と dest_path は他の多くの人が指摘するように、ひとつのハマりポイントなので注意すること。通常、バックアップする場合は、あるフォルダーを丸ごと NAS にコピーする意識で行う。こういった場合、 src_path の指定はフォルダー名で終わり、/ を付けない形で記述する。/ を最後に記述してしまうと、そのディレクトリの中の各ファイルを意味してしまい、バックアップ先に、そのディレクトリ直下の各ファイルが直接ぶち撒けられる形となるので、要注意。 一方、 src_path の指定をフォルダー( src_folder )にした場合、 dest_path は、そのフォルダーが置かれるべきパスにするべきである。つまり、バックアップ元の最後尾にあるフォルダー名は抜いた、そのフォルダーが配置されるべきディレクトリ名を指定する必要がある。初回のバックアップでは失敗しても気付かないかもしれないが、もし失敗した場合、同じフォルダー名のディレクトリが二重で置かれることになる。次回のバックアップでも同じ指定をするのなら、それでもいいのだが、もし一貫性がないと、前回のバックアップと別物として扱われ、差分ではなく、また新たに丸ごとがバックアップされてしまうようなことにもなりかねない。 例えば、自機の ~/mydata

Linksys WUSB54G v4 と Linux

イメージ
Linksys WUSB54G-JP を昔、オークションで中古ルーターを落札したときのオマケで入手したものの、ほとんど使われる機会のないまま眠らせていた。ふと今使っている Linux (Ubuntu) マシンで有線 LAN の代わりに使おうと思って調べてみたら、あっけなく上手く行った。 WUSB54G-JP はアメリカ版の WUSB54G v4 と同じもののようで、v1~3 と違って v4 だけチップが Ralink 製で、Ralink チップ用のドライバー(p54usb)で動くとの話。今使っている Ubuntu 15.04 では標準でモジュールが含まれているようなので、modprobe するとすぐに動くようになった: sudo modprobe p54usb ひとつだけクリアしなければならない問題があって、このドライバーは、省電力機能がちゃんと対処できていないため、通信がブツ切れになってしまい、例えば、インターネットラジオなどを聴くに耐えない状態になる。 これに対する対処法は省電力機能全体を無効化してしまうこと: sudo iwconfig wlan0 power off これで見違えるようにスムーズな通信が確立できる。 あとはこの iwconfig コマンドを PC を起動する毎に入力するのもバカらしいので、起動スクリプトで実行するようにしておけばいい。 uwsb54gv4.sh という名のスクリプトでも作って、そこにコマンドを記述する: #!/bin/sh iwconfig wlan0 power off これを /etc/init.d に移動し、パーミッションを適当に設定し: sudo mv wusb54gv4.sh /etc/init.d chmod 755 /etc/init.d/wusb54gv4.sh 最後に、起動スクリプトとして設定する: update-rc.d /etc/init.d/wusb54gv4.sh ※起動時はこれで自動で省電力機能の無効化コマンドが実行されるわけだが、ルーター側を再起動するなりして、何らかの拍子に Wi-Fi の接続が一旦切れてしまったような場合は、ドライバーがリセットされて省電力機能が復活してしまうので、都度 iwconfig コマンドで無効化し直す必要があることには留意する