tDiaryのログをファイルに書き出す

Webrickで動かしているtDiaryは、ログが標準出力に吐き出されて不便な事があるので、起動スクリプト側で/var/log配下に吐き出すようにした。
webrickからunicornにすれば、そもそも解決しそうだがとりあえず応急処置。

# chkconfig: - 60 1\5
# processname: tDiaryServer
# pidfile: /www/html/tdiary/tdiary.pid
# description: tDiary Server

RBENV_ROOT=/opt/rbenv/
PATH=$RBENV_ROOT:/sbin:/usr/sbin:/bin:/usr/bin
DESC="tDiary server"
NAME=tdiary
PIDFILE=$NAME.pid

TDIARY_PATH="/www/html/tdiary"

case "$1" in
 start)
  echo -n "Starting tDiary..."
  cd $TDIARY_PATH
 (/opt/rbenv/shims/bundle exec tdiary server -p 51980 >> /var/log/tdiary`date  +%Y%m%d`.log 2>&1) &
  ;;
 stop)
  echo -n "Stopping tDiary..."
  kill -9 `cat /www/html/tdiary/tdiary.pid`
  ;;
 restart)
  $0 stop
  $0 start
  ;;
 status)
  status -p `cat /www/html/tdiary/tdiary.pid` tdiary
  ;;
 *)

echo "Usage:$0 {start|stop|restart}"
exit 1;
;;

esac

webminをnginx+SSLでサブディレクトリで動かす

  • webminはrpm等で導入済とする
  • デフォルトポートは変更する。
  • SSLはnginx経由とする
  • https://example.com/webmin_subdirectory/でアクセスできるようにする

/etc/webmin/config

webprefix=/webmin_subdirectory
webprefixnoredir=0

/etc/webmin/miniserv.conf

port=25252
front_url=https://example.com/webmin_subdirectory/

/etc/nginx/conf.d/ssl.conf

server {
 listen 443;
 root /www/html/;
 server_name example.com;
 client_max_body_size 25M;
 ssl on;
 ssl_certificate	 /etc/nginx/cert/server.crt;
 ssl_certificate_key  /etc/nginx/cert/server.key;
 
#Webmin Setting

 location /webmin_subdirectory/ {
 proxy_redirect http://example.com:25252/ https://example.com/webmin_subdirectory/;
 proxy_pass http://127.0.0.1:25252/;
 proxy_read_timeout 3600s;
 proxy_set_header    X-Real-IP	$remote_addr;
 proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header    Host            $host;
 proxy_set_header X-Forwarded-Proto $scheme;
 }
}

nginx、Webminの再起動でhttps://example.com/webmin_subdirectory/でアクセス可能となる。


SQL Server 2012 expressでODBC接続できない

仕事で複数人で同時編集したいデータがでてきたのでRDBMS化を検討。

検証用にFAT端末にインストール。2008だとほとんど初期設定のままODBC接続できたのに、すんなりできなくて軽く震えている(トラシューしている暇ないので)

TCP/IPも有効にしたし、Firewallも無効にしてみたし、Portも設定してみたし。とりあえず、それっぽいキーワードででたサイトを明日、職場で見てみることにしよう。

結果。

SQLサーバ側で「構成マネージャー」→「プロトコル」の「TCP/IP」の設定不足。

TCP/IP接続を有効にするまでは、わかる。

TCP/IPのプロパティを見ると、デフォルトで各IFの「有効」が「いいえ」になっており無効化されている。「有効」を「はい」にして有効にしなくてはならない(ハマリポイント1)

実IPアドレスとループバックアドレスを有効にした。

さらにlistenポート番号を指定する場合は、個々のポート設定部分ではなく、設定最後のipall部分でポートを指定しなくては最終的には有効にならない。(ハマリポイント2)

ここまで設定してから、SQLサーバのサービスを再起動すれば、TCP1433とUDP1434で待ち受けしてくれる。

なおサーバ側でポートを固定値にした場合は、ODBC側でも設定時に動的ポートを外す必要がある(NativeClientの場合は不要)



//追加