カテゴリー別アーカイブ: Linux

NginxでWordPressを動かす@Ubuntu 14.04 LTS

少し流行は過ぎてしまったのですが、UbuntuのnginxでWordPressを動かしたのでメモ。

1. 構成
まずは構成について。
ウェブサーバの構成について、単にnginxを使うとしてもいろいろな構成があるんだけれど、今回はリバースプロキシを使った構成にしました。

リバースプロキシはユーザからのリクエストを受ける際、いったんプロキシサーバがリクエストを受け取って、それを本当のウェブサーバに問い合わせを行う、というそんな機能を提供してくれます。
プロキシ(代理)サーバなので、リクエストを途中から代理してくれる、そんなサーバです。
リバースと付いているのは、リバースじゃ無い普通のプロキシサーバもありまして、こちらはクライアント側で利用します。リバースプロキシはリバース、逆向きなので、サーバ側において代理させるんですね。
ちなみにリバースプロキシサーバ、プロキシサーバともにキャッシュ機能が付いている物がほとんどです。

で、今回の構成では、インターネット側からのリクエストをnginxのリバースプロキシで受けて、それを内部のnginxへリクエスト、そのnginxはWordPressに必要なPHPをPHP-FPMというものを使って動作する、ということに。
このリバースプロキシを使うことでキャッシングが容易にできるのでWordPressの高速化が進む、というものですね。

ちなみにPHP-FPMはプロセスで待ち受けさせていて、リクエストがあるとすぐにPHPを実行して結果を返すという、そういう仕組みをもったPHPのサーバ、デーモンです。

一台のサーバで”リバースプロキシ”、”ウェブサーバ”、”PHPサーバ(アプリケーションサーバ)”を動かす必要があるので、そのやりとりにはいくつかのルールが必要です。
サーバへリクエストを投げるときには必ず、どのサービスへ繋ぐか、という情報が必要なのですが、これを通常ポート番号によって振り分けるのです。
ちなみに一般的なウェブサービスだと80番を利用します。またプロキシサーバでは8080版を利用します。

今回はリバースプロキシですのでこいつが80番で待ち受けて、このリバースプロキシからウェブサーバへはウェブサーバの8080番ポートへ接続、PHPが動いているデーモンへはポート番号じゃなくてsockという仕組みで繋ぐことにしました。

2. 手順
まずはインストール。ubuntuなのでaptを利用します。今回必要になるのはnginx, php-fpmです。

shell> sudo apt-install nginx php-fpm
shell> cd /etc/nginx

インストールが終わったらnginxのデフォルトコンフィグが格納されている/etc/nginxで作業します。

まずは早速、WordPressに必要なnginxのconfigを二つ書きます。
これはWordPressの公式サイトで紹介されています。二つのconfを/etc/nginx/siteconf.d/というディレクトリを作って配置しています。

more /etc/nginx/siteconf.d/global_restrictions.conf       
# this file is from http://codex.wordpress.org/Nginx                            # Global restrictions configuration file.                                       
# Designed to be included in any server {} block.</p>                           
location = /favicon.ico {                                                       
         log_not_found off;                                                     
         access_log off;
}

location = /robots.txt {
         allow all;
         log_not_found off;
         access_log off;
}

# Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Sto
re (Mac).
# Keep logging the requests to parse later (or to pass to firewall utilities suc
h as fail2ban)
location ~ /\. {
         deny all;
}






shell> cat /etc/nginx/siteconf.d/wordpress_base
# this file is from http://codex.wordpress.org/Nginx

# WordPress single blog rules.
# Designed to be included in any server {} block.

# This order might seem weird - this is attempted to match last if rules below fail.
# http://wiki.nginx.org/HttpCoreModule
location / {
         try_files $uri $uri/ /index.php?$args;
}

# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# Directives to send expires headers and turn off 404 error logging.
location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
       access_log off; log_not_found off; expires max;
}

# Uncomment one of the lines below for the appropriate caching plugin (if used).
#include global/wordpress-wp-super-cache.conf;
#include global/wordpress-w3-total-cache.conf;

# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ \.php$ {
         # Zero-day exploit defense.
         # http://forum.nginx.org/read.php?2,88845,page=3
         # Won't work properly (404 error) if the file is not stored on this server, which is entirely possible with php-fpm/php-fcgi.
         # Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine.  And then cross your fingers that you won't get hacked.
         try_files $uri =404;

         fastcgi_split_path_info ^(.+\.php)(/.+)$;
         #NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini

         include fastcgi_params;
         fastcgi_index index.php;
         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
         fastcgi_param REMOTE_ADDR  $http_x_real_ip;
#        fastcgi_intercept_errors on;
         fastcgi_pass unix:/var/run/php5-fpm.sock;
}

最初のglobal_restrictions.confでは不正なアクセスを防ぐための設定です。nginxでは.htaccessを初めとしたファイルを利用しませんので、それらのファイルが標準では直接表示されたりします。中にはパスワードを書いてあったりすることもあるので安全のためこれらのファイルを非表示にするconfです。

続いてwordpress_base.confです。これがnginxとphp-fpmでwordpressを動かすための基本的なconfigになります。ほとんどは公式通りなのですが、注意点がいくつかあります。
conf本体の下部にある、 “fastcgi_param REMOTE_ADDR $http_x_real_ip;”については追記してあります。
これは今回リバースプロキシを使うに当たって、ウェブサーバで見えるクライアントIPアドレスが127.0.0.1のような自分自身のアドレスになってしまうことを防ぐ処置です。
自分自身をリバースプロキシにする場合に限らず何らかのリバースプロキシを挟むとREMOTE_ADDRが書き換わってしまいます。そうするとアクセス解析やコメントをつけた人のIPアドレスがすべて同じものになってしまい意味のないものになってしまいます。
それを防ぐための構文になります。ちなみにapacheであればmod_rpafというモジュールで対処したりします。
もう一点気をつける構文は”fastcgi_pass unix:/var/run/php5-fpm.sock;”です。今回はPHPとnginxを動かすサーバが同じサーバでしたのでsockを利用しました。他のホストで動かす場合やTCP/IPで動かす場合には変更が必要です。

これでwordppressの基本的なconfは揃いました。続いてはサイトのconfを書きます。

最近はnginxもapache同様、ドメインごとにconfigを書いてシンボリックリンクで有効化/無効化する流れになっています。今回は /etc/nginx/sites-available/example.com で作成しました。
このconfにはリバースプロキシ用の設定も含まれるので少し大変です。

shell> cat /etc/nginx/sites-available/exampel.com.conf
server {
        listen 80;
        server_name www.example.com;
        root        /home/yousan/public_html/www.example.com;
        index index.html index.htm index.php;
        include siteconf.d/global_restrictions.conf;

# ここから下がリバースプロキシ用の設定 最後にドメインの名前を設定すること
# またnginx.confのbackednともセットで設定すること
              location /wp-admin { proxy_pass http://backend; }
              location ~ .*\.php { proxy_pass http://backend; }
        location / {
              set $mobile "";
              if ($http_user_agent ~* '(DoCoMo|J-PHONE|Vodafone|MOT-|UP\.Browser|DDI
POCKET|ASTEL|PDXGW|Palmscape|Xiino|sharp pda browser|Windows CE|L-mode|WILLCOM|SoftB
ank|Semulator|Vemulator|J-EMULATOR|emobile|mixi-mobile-converter)') {
              set $mobile "@ktai";
              }
              if ($http_user_agent ~* '(iPhone|iPod|Opera Mini|Android.*Mobile|NetFr
ont|PSP|BlackBerry)') {
              set $mobile "@mobile";
              }
              if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-post
pass_" ) {
              set $do_not_cache 1;
              }
              proxy_no_cache     $do_not_cache;
              proxy_cache_bypass $do_not_cache;
              proxy_cache czone;
              proxy_cache_key "$scheme://$host$request_uri$is_args$args$mobile";
              proxy_cache_valid  200 301 302 60m;
              proxy_cache_valid  404 5m;
              proxy_cache_use_stale  error timeout invalid_header updating http_500
http_502 http_503 http_504;
              proxy_pass http://backend;
              proxy_redirect http://www.example.com:8080/ /;
       }
}

server {
    listen      8080;
    server_name www.example.com;
    index index.html index.htm index.php;
    include siteconf.d/global_restrictions.conf;
    include siteconf.d/wordpress_base.conf;
    root            /home/yousan/public_html/www.examplecom.com;
}

shell> sudo ln -s /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled

このconfでは上のserverディレクティブで80番の待ち受け、リバースプロキシ側の待ち受けを設定します。この中で最後の方にあるproxy_redirectという構文で実際にPHP等が動いている8080で待ち受けをしているウェブサーバへ転送しています。
下の8080で待ち受けをしているところは先ほどwordpress用のconfを書きましたのでそれらをincludeして、あとは少し書いてやるだけでOKです。

ドメインごとのconfを書いたらlnでシンボリックリンクをsites-availableへ移してあげてください。こうすることで有効化されます。

最後にnginx本体のconfを書きます。
今回はリバースプロキシでレスポンスを早くしよう!というが目的ですのでリバースプロキシのキャッシュとgzip圧縮を有効化します。
ココでもリバースプロキシ用の設定を分けてあります。
機能別に分けられたconfはconf.dに入れると自動で読み込まれますのでそちらに入れておきます。自動に読まれますけれど*.confという名前じゃないとダメなので注意してください。

shell> cat /etc/nginx/conf.d/
proxy_cache_path  /var/cache/nginx levels=1:2 keys_zone=czone:4m max_size=50m inacti
ve=120m;
proxy_temp_path   /var/tmp/nginx;
proxy_cache_key   "$scheme://$host$request_uri";
proxy_set_header  Host               $host;
proxy_set_header  X-Real-IP          $remote_addr;
proxy_set_header  X-Forwarded-Host   $host;
proxy_set_header  X-Forwarded-Server $host;
proxy_set_header  X-Forwarded-For    $proxy_add_x_forwarded_for;
proxy_set_header  Remote-Addr        $remote_addr;
#real_ip_header X-Forwarded-For;
#real_ip_recursive on;

upstream backend {
             ip_hash;
             server 127.0.0.1:8080;
}

こちらが本体側のconfです。ほとんど書き換えてないのでコメントを外すだけですね。

shell> cat /etc/nginx/nginx.conf
... 省略 ...
       ##
        # Gzip Settings
        ##

        gzip on;
        gzip_disable "msie6";

        gzip_vary on;
        gzip_proxied any;
        gzip_comp_level 6;
        gzip_buffers 16 8k;
        gzip_http_version 1.1;
        gzip_types text/plain text/css application/json application/x-javascript tex
t/xml application/xml application/xml+rss text/javascript;

これでconfが整いました。
最後にnginxを再起動して動作確認です。

shell> sudo service nginx restart

さて、動いたでしょうか。

今回自分もすぐには動かず、いくつかはまった点がありましたので紹介しておきます。
1. 文末のセミコロン忘れ
2. www.example.comというドメインのまま、ドメイン名を書き換え忘れていた
nginxではほとんどの文末にセミコロンをつける習慣がありますので、これを忘れるとエラーになります。
ドメイン名の書き換えでは色んなサイトを参考にしながらconfを書いたのですが、confの途中にドメイン名がでていて、今回実際に運用するドメインに書き換えるのを忘れていて動きませんでした。

これらのエラーについてはerror.logを見る事でどのファイルのどこでエラーが起きている、ということが分かったりします。

shell> sudo tail /var/log/nginx/error.log

ただ中には直接的にエラーが表示されず、推測に推測を重ねてエラーを取り除く必要もありますがそちらについては…、経験が物をいいますね!

以上となります。

mkvをmp4に変換するバッチスクリプト

mkv2mp4_flac1

よく使う割には手順が多くて面倒なのでバッチを作った。

h.264 + FLACなmkvファイルをmp4に変換する。
中身のFLACファイルはmp4には入らないので、AACに変換。
可変フレームレート対応。

使い方など
mkv2mp4_flac1 -v 0 -a 1 file.mkv [file2.mkv] [file3.mkv] …
事前に、ファイルのトラック番号をffmpegなどで調べる。
-v < ビデオトラックID> -a < オーディオトラックID>
ファイルは指定しただけ処理される。

続きを読む mkvをmp4に変換するバッチスクリプト

UNIX/Linux環境でFTPを再帰的に拾ってくる方法

こんにちは、岡田洋一です。

UNIX/Linux環境でFTPのディレクトリをまるごと取りたかったんです。が、ftpコマンドだとディレクトリを取ろうとしてもダメなんですね。

get somedirectoryってやるとNot a regular fileって怒られます。

shell> ftp ftp.example.com
Connected to ftp.example.com.
220 ::ffff:192.0.2.1 FTP server ready
Name (ftp.example.com:user): user
331 Password required for user
Password:
230 User user logged in
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get tmp
local: tmp remote: tmp
550 tmp: Not a regular file

ディレクトリを再帰的に取りたい、っていう場合にはwgetを使うと良いようです。

shell> wget -r ftp://user:[email protected]//path_to_get/

多くの環境でインストールされているwgetで、ワンライナーで取得できるのはいいですね。

参考:  How do you recursively ftp a folder in linux

Debian/Ubuntuのコードネームを確認する方法

梅雨が明けたとか明けないのかよく分からない天気が続きますね。僕のダイエットもいつ明けるのか全く不明です。

岡田洋一ですこんにちは。

さて最近はDebian/Ubuntuをよく利用しています。以前はUnix/Linuxと言えばFreeBSD一択だったのですが、どうにも世の流れはLinuxということでお手軽なLinuxに移行しつつあります。日本ではCentOSが根強い人気を持っていますが海外の情報が少なく、また自信の周りの友人がDebian/Ubuntu派だったためDebian/Ubuntuを利用しています。

さてそんなDebian/Ubuntuですがこれらにはコードネームがついているんですね。5.0 -> 6.0といった具合にメジャーバージョンが変わったときには必ずこのコードネームが変わります。

このコードネームですが利用する上で知っておくことが必要になることがあります。パッケージ化されているソフトウェアはOSのバージョンによって違ってきますのでコードネーム名がついて配布されていたりします。またパッケージ管理ツールのaptもコードネームベースになっています。

そんなコードネームは /etc/os-release を見ることで確認できます。

shell> cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 7 (wheezy)"
NAME="Debian GNU/Linux"

VERSION_ID="7"
VERSION="7 (wheezy)"
ID=debian
ANSI_COLOR="1;31"
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support/"
BUG_REPORT_URL="http://bugs.debian.org/"

ところでDebianのコードネームはトイストーリーのキャラの名前なんですね。知らなかったです。

Debianのコードネーム一覧
Debian GNU/Linuxのバージョンと名前(コードネーム)|星屋工作室 hoshiya.biz

またLinuxのディストリビューション名を確認するときには /etc/issues を参考にすると良いです。

shell> cat /etc/issue
Debian GNU/Linux 7 \n \l

unameで確認できない時にこちらの方法で確認できたりします。

NIS, LDAPを用いた複数の環境でログインシェルを変更する

NIS, LDAPを用いた複数の環境でログインシェルを変更したかった。

現在自分の環境ではLDAPを利用している。ログイン情報をLDAPサーバに集約できるので非常に便利。LDAPではログイン時にユーザ名、パスワード(ハッシュ)などの情報を各ホストに提供するのだけれど、その中にはログインシェルも含まれる。

ログインシェルといえばUNIX系でよく使われるcsh, tcsh、Linux系でよく使われるbash、また高機能シェルとして名高いksh, zshなどがある。自分はzshをメインのシェルとしているのだけれど、LDAPのログインシェルの情報をzshに変更するだけでは問題がある。

まず一つ目はフルパス表記での問題だ。
ログインシェルは通常フルパスで表記される。これはシェルの初回立ち上げ時に~/.cshrc, ~/zshrcといった環境ファイルを読み込ませ、その段階でパスがセットされるからだ。つまりログインシェルの情報を取得して起動させる段階ではパスが通っていないことが想定される。そしてこのフルパス表記がOS毎に違ってくる可能性がある、ということが問題の核だ。
このシェルの実体、バイナリの実体が配置される場所は大まかに以下のようになる。Linux系ではrpm, yum, aptなどのパッケージ管理ツールでインストールした場合の/usr/bin/、デフォルトで配置される/bin/、ソースからインストールされた/usr/local/binである。
対してFreeBSDの場合、tcshやcsh, shなどの元々インストールされているバイナリは/bin/sh, /bin/tcshなどに配置されるが、後から手動でインストールされたバイナリは/usr/local/binに配置される。zshやbash(FreeBSDではbashがデフォルトで入ってこない)は/usr/local/binに置かれている訳だ。
この問題に関して言えば、インストール時にバイナリの配置場所を/usr/bin, /bin, /usr/local/binのいずれかに統一してしまう、若しくはシンボリックリンクを統一された場所に配置する、という解決方法が考えられる。でもこれらの作業をそれぞれのホストでいちいち実行するのは億劫だ。

二つ目の問題はデフォルトでインストールされるシェルが少ないことだ。自分の環境では主にFreeBSD、またDebian系(Ubuntu)、RHEL系(CentOS)、さらにはMac OS Xと数種類のOSを利用している。その中でデフォルトでインストールされるシェル、となると実は結構少ない。FreeBSDではcsh若しくはtcshをデフォルトシェルにする事が多い。対してLinuxではbashがデフォルトシェルとなることがおおい。そして残念な事にはFreeBSD/Linuxに於いては(t)csh/bashがお互いにデフォルトでインストールされていない。
ということはbashならbashをLDAPのデフォルトシェルにしてしまって、bashの環境ファイルである.bashrcなどでzshを呼び出す、という事ができない。

以上の点を踏まえながら試行錯誤していった結果、「UNIX/Linuxの両方に入っているシェルを使ってログイン時にzshにしてしまう」という方法にたどり着いた。ちなみにそのUNIX/Linuxの各種OSの最大公約数と言うべきシェルはsh。
shとはThompson shellを意味し、bashの前身となったシェルだ。過去にはバックスペースすら無かった気もするけれど、カーソルキーで入力位置を変更できない、コマンド履歴が使えないというシェルの基本的な機能のみしか持っていない素朴なシェルだ。
(とは言え、過去のbashも同様でデフォルトではコマンド履歴なども使えなかった気がしてbashとshのデフォルト状態での違いがあまり無いような状態だったんだけれど、最近のbashは使いやすいシェルっぽくなってる)
さてLDAPではこのshをデフォルトシェルにし、shが立ち上がった後にzshを呼び出すようにしてみる。

shでログインされた際に呼ばれる環境ファイルは “.profile”ファイルである。”.login”かと思ったんだけれどこれはshだと実行されないしcsh系だった気がする。つまりsh系ではダメということ。
この.profileファイルには直接shに実行して欲しいことを記述する。以下に例を示す。

[ -x /usr/local/bin/zsh ] && exec /usr/local/bin/zsh
[ -x /bin/zsh ] && exec /bin/zsh

shらしい記述で条件式を書き、それぞれのバイナリが存在し実行可能であればexecしてやる。execでシェルを呼び出せばログインシェルが切り替わった動作になるのでCtrl+Dなどでシェルを抜けたときにzshを支えているshも一緒にexitしてくれる。つまりログインシェルがzshになったようにみえてshを意識することが無い。

以上で思っていたようなzshなどのパスが違う環境でログインシェルを統一する、ということが可能になった。

めでたしめでたし。

TeamSpeak3のserveradminのパスワードを忘れてしまった場合の対処法

TeamSpeak3のserveradminのパスワードを忘れてしまった場合の対処法について。

音声チャットソフトTeamSpeak3の管理用アカウントとしてserveradminがあるのだけれど、そのログインパスワードを忘れてしまったときの復旧方法について。管理用ログインを使うといろいろなことができるのだけれど、この管理用パスワードは恐らく初回インストール時、初回サーバログイン時に表示されてよくわすれちゃう。どこかのログに残っていそうなきがするのだけれど探しても見つからないし途方に暮れてしまっちゃう。で、そんなアナタに、そんなワタシにserveradminのパスワード復旧法。

まずは元になった記事の紹介。

A simple ts3 serveradmin password recovery script (win + linux)
というわけでパスワード復旧のスクリプトを配布してくれている人がいました。このスクリプトを使って復旧できます。

上記フォーラムの第一投稿にスクリプト(tar.gz)のリンクがあるのでダウンロードして解凍して実行。これでうまくいきます。中にはwindows用とlinux用のスクリプト、batファイルbashスクリプト、それからsqliteのバイナリが入っている。それぞれの環境で実行してやればうまくいくはず。

このスクリプトを実行すると管理者のパスワードをykN+zfqDに変えてくれる。これでこのパスワードを使ってログインする事ができる。管理者でのログイン方法については他の記事を参照してください

で、もちろん気をつけなければいけないことは、管理者用パスワードをログイン後に変えておくこと、が必要。これは絶対に必要。アナタのTeamSpeak3 serverを守るために必ず行っておいてください。

管理者用のパスワードの変え方については以下の通り。telnetでログインして上記のパスワードでログイン後、”clientsetserverquerylogin client_login_name=serveradmin”を実行する。これで新しいランダムなパスワードが発行される。このパスワードをメモしておきましょう。

login serveradmin ykN+zfqD
 error id=0 msg=ok</b>
 clientsetserverquerylogin client_login_name=serveradmin
 client_login_password=password
 error id=0 msg=ok

どんなスクリプトなの?

というわけで、管理者のパスワードを書き換えるという結構危ういスクリプトなので中身が気になりました。簡単なスクリプトなので中身を覗いてみることに。
中身はsqliteでのいくつかのSQLの発行している。clientsテーブルのclient_id=1な行をserveradminとしてそこのclient_login_passwordをupdateしている。

UPDATE clients
SET client_login_password = "r5oBZ3Z8s8IqjiEJ/k3o9dkSUgU="
WHERE client_id = "1";

更新している内容は恐らくmd5のハッシュだと思われる。ハッシュの元になっているのが先述の”ykN+zfqD”で、このハッシュにアップデートすることでパスワードを変更している。

なるほど、という感じでこれぐらいなら安心できることが確認できました。

FreeBSDとかだとsqliteのデータベースファイルの位置がわかりにくいのだけれど、そこへいって手動でsqliteを実行することでパスワードを更新できた。sudoで変更してあげれるようにしてやらないとダメだけど。

 

というわけで管理者で無事にログインできるようになります。

TeamSpeak3で管理者ログインする方法

TeamSpeak3で管理者ログインする方法について。

無料のボイスチャットソフト、TeamSpeak3。そのサーバを運営していると管理者でログインする必要がでてくる。管理者でのログインはわかりにくいのだけれどその方法についてのメモ。

過去のバージョンだとTeamSpeak3のクライアントから様々なクエリを使うとができていたと思うんだけれど、なぜだか現行バージョン(3.0.9.2)だと無理だったので他の方法で試してみた。
ちなみに過去のバージョンのやり方はTeamSpeak3 Wikiに載っているので参照されたし。

ログインしてクエリを実行するにはtelnetを行う必要がある。telnetは主にTCPを用いたいろいろなコマンドのやりとりをするもので、UNIX/Linuxに入っている。昔のWindowsには付いていたんだけれど最近のWindows 7とかだと見かけない。そういう場合にはTeraPadputtyを利用しよう。

telnetでのログイン

telnetでログインするにはIPアドレス又はホスト名、そしてポート番号が必要だ。IPアドレス、ホスト名についてはクライアントでログインするときに使用しているアドレス、ホスト名を入力しよう。ポート番号についてはデフォルトでは10011。TeamSpeak3では下記のようなポート番号を使っている。10011を3倍したものはファイル転送用だ。

サービス ポート番号
通常の音声チャット 9987 tcp
管理サーバクエリ接続 10011 tcp
ファイル転送用 30033 tcp

サーバ/クエリ


実際にtelnetで接続してみる。まずは “telnet ホスト名 10011″と入力する。接続が完了したら”login serveradmin password”としてログインしよう。

shell> telnet ts.l2tp.org 10011
Trying 192.168.11.1...
Connected to ts.l2tp.org.
Escape character is '^]'.
TS3
Welcome to the TeamSpeak 3 ServerQuery interface, type "help" for a list of commands and "help <command>" for information on a specific command.
login serveradmin passwork
error id=0 msg=ok

うまく接続できない場合にはIPアドレスが正しいかチェックしてみる。該当のホストでnetstat -natsockstat | grep teamspeakなどしてみよう。
ログインするときのserveradminのパスワードが分からない場合にはパスワードをリセットしましょう。

これでサーバへログインできたと思う。この先にはいろいろなことができるのでやってみましょう。

MySQL接続で起こった怪奇現象

今日も引き続いてzabbixの設定をしてました。そのなかでmysqlコマンドを利用してzabbixに接続をさせてあげたかったんです。で、その時のテスト時に不可解な現象が、理解不能な現象が起きました。

MySQL上でzabbixという名前のユーザを作り、ローカルホストのログインのみパスワード無しで接続可能にしたんですね。つまりTCP/IPとかの接続はダメでローカルのsock通信のみOK、ローカルからのmysqlコマンドでつなげばOKと。

ユーザを追加したので鼻歌でも歌いながら接続試験をしてみました。

mysqlhost> sudo -u zabbix mysql
ERROR 1045 (28000): Access denied for user 'hogetan'@'localhost' (using password: NO)

が、繋がらない。見てみるとaccess deniedしてる対象ユーザがsudo元のhogetanになってる!

これじゃ繋がらないよね。でもおかしい。通常sudoすればバイナリを実行するユーザは切り替わるはずなのに切り替わってないご様子。環境変数にその辺りが入ってるのかと思いチェックしてみるも…。

mysqlhost> sudo -u zabbix env| grep hogetan
SUDO_USER=hogetan

うーんむ、怪しい感じではないなぁ。USERとかはちゃんとzabbixになってたし。しょうがないのでnologinを解除してsuしてログインしてやってみることに。

mysqlhost> sudo su - zabbix; env | grep zabbix;
mysqlhost> mysql
ERROR 1045 (28000): Access denied for user 'hogetan'@'localhost' (using password: NO)
mysqlhost> env | grep hogetan

うーむ……。最後のenvはhogetanにヒットするものが無かった。一体ドコの情報を参照しながら元のsudoユーザ名でmysqlコマンドをつなごうとしてるのだろうか。

結局、結局結局、mysqlコマンドに-uでつながせることで落着はしそうなのですが、何とも腑に落ちない結末でした。

ちなみにですがsudoをするユーザをfugatanとかにすると確かに今度はfugatanでrejectされてるんですね。なのでmysqlコマンドがかならずhogetanユーザになる、というわけでもなさそうです。またmysqlホスト、sudoを行う場所をlinuxで試してみたらこれはちゃんと所望の結果が得られました。

FreeBSD特有の挙動なのかなぁと思いながら今夜も寝れなさそうです。

解決やお心当たりのある方は是非教えて下さい。

sedを使ってファイルの中身を置換する

sedを使ってファイルの中身を置換したかった。
ヒトクセあるsedだけどコマンドラインでさっくり置換してくれるのは魅力。
置換となるとファイルの中身を書き換えて欲しかったりするんだけどファイル自身を書き換えるときのオプションを調べたのでメモ。二回目なのでメモ。忘れていたのでメモ。

FreeBSDはオプションがLinuxなどの GNU sed と違うらしい。ファイル自身を書き換えるオプションがGNU sedなら-iでいける。でもFreeBSDであれば-iは引数を伴いそのファイル名で出力する、というものなのだ。で、ファイル自身に書き出したいときにはシングルクォートで引数に空文字を渡してやればそれ自身を書き換えることができる。めもめも。

shell> sed -i '' 's/hoge/fuga/g' inputfile