■

どうも。
自分はUSBにUbuntuをインストールしてVAIOにぶっ刺して利用しています。
このVAIOですが、NVIDAのグラフィックボードを搭載しており、Ubuntuの運用にちょいちょい手間がかかるのでメモしておきます。


同様のケースが稀かもしれないので完全に備忘録的なものです。

  • ケース1.ログイン画面までたどり着かない
  • ケース2.ログイン画面が繰り返す


どちらも結局はUbuntuのアップデートによって発動するトラップですが原因はNVIDIA関係でした。
修復というか、高解像度での利用に復旧する術は色々ありましたが、結局のところどちらのケースも同じ方法でも復旧出来ました。


ケース1ではboot時にfsckが繰り返されてログイン画面まで到達出来ないというケース。
そんなときはCtrl+F1でCUIでログインし、復旧作業実施。


ケース2ではログイン画面までは到達するもののアカウント情報を入力してもログイン画面に戻されるというケース。
こちらもログイン画面でCtrl+F1でCUIにてログインし、復旧作業実施。


で、肝心の復旧作業は
アップデートで適用されたであろうNVIDIA関係をpurgeする。

udo apt-get purge nvidia*

自分の場合はこれで解決。
以上！

Vagrantでのhost-only adapterのエラーを回避する方法 on Windows10

はい。どうも。
7月29日にWindows10のアップデートが配信され、
私も速攻でアップデートしました。
仕事で利用しているPCはソニー時代のVAIO Pro 13ですが、本当に目立った不具合もありませんでした。
1つだけ、Vagrantを利用しているのですが、
アップデートしたことでVagrantから仮想マシンが起動出来ませんでした。
ちなみにVitrualBox UIからは普通にguest OSは起動できる。
ネットをみるとどうやらWindows10にアップデートした人が起動に失敗している模様。
※エラー内容は以下↓

vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set network interfaces...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["hostonlyif", "create"]

Stderr: 0%...
Progress state: E_FAIL
VBoxManage.exe: error: Failed to create the host-only adapter
VBoxManage.exe: error: Code E_FAIL (0x80004005) - Unspecified error (extended in
fo not available)
VBoxManage.exe: error: Context: "enum RTEXITCODE __cdecl handleCreate(struct Han
dlerArg *)" at line 70 of file VBoxManageHostonly.cpp

どうもVagrantというか、VirtualBox側のhost-only adapterでのネットワーク作成時に権限周りが邪魔をしてエラーとなっているようです。
（根本のエラーは違うみたいだけど）
ということで、世界中のWindows10にアップデートしたVagrantユーザーが阿鼻叫喚。
実は、報告自体はちょっと違うけど根本は同じエラーが4ヶ月ほど前にもVirtualBoxへも報告されているようでticketがありまいた。
エラー内容が同じということでこのticketに多くの人が殺到。
いくつかの回避策が報告されてたりもしてたんですが手順が複雑だったりしていました。
そこでもともとticketを切った方がこれを簡単に回避するexeアプリを作成し公開してくれたのでこれをちょっと報告したいと思います。
といっても簡単。
ticketに添付されているアプリをダウンロードし、実行中にvagrant up（host-onlyのネットワークを作成）するだけです。

  1. ここ（https://www.virtualbox.org/ticket/14040）からVBox-Win10-fix-14040.exeをダウンロード
  2. 右クリックして管理者権限として実行
  3. 以下のアプリが起動中にvagrant up

無事に起動できました。以上！
※ただし、VirtualBoxのアップデートで正式に対応されるまでの暫定ソリューションです。

Wordpressでメディアを削除する権限

[wordpress]
Wordpressでサイト構築中に、ページ入力してもらってるユーザーは構築中の他のページを見てもらいたくないように新しいRoleを作って対象ページ（カスタム投稿）のみ編集できるようにしていた。
が、アップロードしたメディアが削除出来ないとのこと。
Roleの追加は「User Role Editor」を使って特定のカスタム投稿とファイルのアップロードのみを許可していたつもりだったけど削除できない様子。
User Role Editorの設定画面を見てもupload_filesに対するedit,やdeleteのcapabirityがない。。

色々調べたところ、メディアはothers_postsに属するっぽいので、
編集は、edit_others_posts
削除は、delete_others_posts
となるもよう。

というか、

感覚てきには多分他の投稿記事も編集・削除権限を与えつつ、投稿や固定ページの編集権限を与えない
という条件が、
メディアの編集・削除ができる

ということになるのかな？

まぁ、これでやりたい権限設定は実現できた。

■

WordPress

Webサイトを作るという仕事がもっぱらWordPressを使い倒すとう作業が最近のもっぱらの仕事になっていますが、最近、セキュリティに対しての意識も高まってきていることで、過去導入したCMSのアップデートなどの話がクライアントから積極的に出てきます。

ちょっと前までなら、「御社専用にカスタマイズしているので云々・・」ということで導入Ver.からアップデートしないという選択肢もありましたが、、
（※いや、実際カスタマイズしていたらアップデートの作業ボリュームって結構なボリュームになることもあるのですよね）

ということで、つい先日も「WordpressのVer.をあげたいんだけど！セキュリティ的にもなんかあげなきゃ！」という声をいただきました。
実際Wordpressがこれほど普及した定めか、攻撃対象のCMSとして目立っていることも確かですね。

さて、前置きが長くなりましたが、今回バージョンアップ対象となるWordpressにはいくつかPluginを導入していますが、qTranslateという多言語用Pluginが本体のバージョンに追随してアップデートしていない(開発停止状態？)影響で、これまでWordpress本体バージョンをアップデートできずにいました。
とはいえ、お客さんにこのままバージョンアップしないで運用してくれと言うのも忍びないので対応できるかどうかを調査したところ、あるじゃないですか後継となるPluginが！
どうやら、先に導入していたqTranslateは素の役目を終え、qTranslate-Xという新しいPluginに開発を引き継いでいるそうです。
参照：http://www.grooving-earth.com/qtranslatex/

ということで、スクリーンショットとるほどでもなかったので簡単にステップを。

Wordpress(3.8)＆qTranslate(2.5.34)からWordprss(4.2.2)＆qTranslate-X(3.3)へ

  1. qTranslateを停止
  2. WordPressのアップデート
  3. qTranslate-Xのインストール及び有効化
  4. テンプレート修正
  5. qTranslate-Xに関連するもろもろ。
補足

1〜2番までの作業は得に問題なく進めるとおもいます。
2番の作業後、管理画面が真っ白になるという現象に合いましたがerror_logからopen_basedirのエラーと分かったのでphp.iniのopen_basedirをコメントして無効化。改めて管理画面したところ問題なく表示・ログインできました。
3番も特に問題ないかと思いますが、qTranslate-Xを有効化したあと、管理画面の至る所でメッセージがでますが一旦スルー。
4番目qTranslateで使用していた関数が軒並み使えなくなるものの、以下修正で問題なく動作（エラー吐いてないんで多分大丈夫）
qtrans_getLanguage -> qtranxf_getLanguage
おそらく名前空間というか、関数の命名ルールで「qtrans_」から「qtranxf_」にしてるんだろうなと適当に推測。
5番目の関連諸々は、なんかちょっと上でも書いた管理画面に色々メッセージでるよ！ってことの対応ですが、多分「-X」になったことで色々オプション増えたよ！ってこと通知や、他のPluginと連携したら色々統合できるよって内容のメッセージだったのでそこは個人の判断で。

ということでバージョンアップできてよかった。

Pleskのweb_usersからのシンボリックリンク

お久しぶりです。

今日は、Pleskを使っていて軽くハマったポイントを備忘録的に。。

お題：
Pleskで設定されたドメインのドキュメントルート配下にWeb_Usersで作成したユーザーのファイルを公開したい。
http://xxxx.com/yyyy/ ⇠yyyyがWebユーザーのFTPルートディレクトリ。

背景としては、アクセスを制限したFTPユーザーを追加したいということでPleskでFTP追加を試みるも、
Pleskのバージョン依存なのかどうか詳しく追ってませんが、
ドメインに対して１つしかFTPアカウントが設定できない。
※ただしWeb_Usersは複数登録可能。
という仕様からお題につながります。

ということで、
普通にPleskから対象のドメイン（xxx.com）に対してWebユーザー作成。

その後、ドキュメントルート下からシンボリックリンクを設定。
$ cd httpdocs/
$ ln -s /var/www/vhosts/xxx.com/web_users/yyyy yyyy

そうすると
$ ls -al
lrwxrwxrwx 1 root root 48 6月 12 15:13 yyyy -> /home/httpd/vhosts/xxx.com/web_users/yyyy/

となるわけですが、ブラウザアクセスでは403のForbiddenとなる。。
うーん、リンクの貼り方を間違えたかなと色々思案し、error_logを見ると
Symbolic link not allowed or link target not accessible
と出ている。

シンボリックリンクが許可されてないのかなーと、
/etc/httpd/conf/httod.confを確認するとOptions Indexes FollowSymLinksの文字はある。。
でもダメ。。
設定反映されてないのかなーと、対象ドメインの/var/www/vhosts/xxx.com/conf/vhosts.confに改めて追記。

んでhttpdを再起動したらちゃんと見えました。

■

WordPress

さて、久しぶりですが、
仕事でWordpressを使うことが多いですが、今回はWebサーバーx3という冗長化構成。


ネットでさらっと調べるとDBの冗長化についてはレプリケーションとHyperDBというプラグインを利用することで対応出来そう。だけど、メディアやテンプレートといったDBの情報ではなく、物理ファイルの対応についてはあまりネット上にない様子。


AWSを使ったたりその他のストレージサービスを利用したメディアファイルの管理については、プラグインなんかで対応できるようだけど、さすがにBtoBの構成にWebサービスは利用できない。
その代わりに、メディアのupload先をWordpressの設定を変更して、各Webサーバーにマウントしたの共用ストレージ（NFS）へ保存するというやり方で運用フェーズでの冗長化構成はこれで行けそうというところまでこぎつけた。


開発中なのでテンプレートなどのローカルファイルは各サーバーに随時反映してあげないといけないけど、これもrsyncでリアルタイム同期をさせるかどうか、、、

どなたかWordpressの冗長化実績があればアドバイスくださいーーーー

■

WordPress

WordPressを触る。
テンプレートタグ？というか関数？を使って出てくるナビゲーションメニューを変更したいので
functions.phpに今回対象のクラスを継承したものを作成。
あとは変更したいfunctionをオーバーライドする。

今回はwp_nav_menuで出力されるliを消したいので
function end_el(&$output, $item, $depth) {
output .= "\n";
}
みたいな。