2017年03月21日

このエントリーをはてなブックマークに追加
Pleskサーバーで検証をしていました。新しいPleskサーバーに各種設定やデータを移動させるのは非常に簡単です。

しかしインストールされているApacheなどのバージョンが異なりますので、微妙に動作がちがってきます。

AH00529: /var/www/vhosts/ドメイン/httpdocs/test/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/var/www/vhosts/ドメイン/httpdocs/test/' is executable


なお以下のような感じでした。所有者以外は読み込み書き込みできないみたいです。
drwx------ 7 TEST psacln 4.0K 6月 23 2016 test/

これが原因のようでした。
ということで、 権限を 755 にしてしまいました。

chmod 755 /var/www/vhosts/ドメイン/httpdocs/test

drwxr-xr-x 7 TEST psacln 4.0K 4月 22 19:08 test/

これで無事に htaccess を読み込むことができるようになりました。

stock_value at 19:22|この記事のURLComments(0)TrackBack(0)技術 

2017年03月20日

このエントリーをはてなブックマークに追加
新人が入ってくる時期ですね。
僕が初めて新人の面倒を見るようになったときから、一環してやってもらっている作業があります。
それが手書きで日報を書いてもらうというものです。

もともとは、メールの文章があまりにも変だったので、一度文章力を見てみたいので、手書きで日報を書いてもらったのがきっかけだったように思います。手書きの理由は、非常に単純でその方が返信を書きやすいからです。あとは、漢字などの使用量や、誤字脱字の多さなども確認できます。
ちなみに日報のクオリティと仕事のクオリティは全く関係ありません。
字が上手でも仕事だめな人もいましたし、そうじゃない人もいました。誤字脱字が多くて頭を抱えるような人でも、仕事は問題なかったり。全く関係ありません。


僕はアナログであることがとても大切だと思っています。
一つはファイルに保管し、次の世代の人が先輩の日報を確認できるということです。
今バリバリと働いている先輩も、かつては新人だった時代があります。そして今の新人と同じように日報を書き、それがファイルされて残っているのです。これを新人が確認することで、モチベーション?につながる可能性があります。

文章の構成力がわかります。
これはこれから仕事をするなかで、メールを書くことが普通になります。このときに、あまりにもひどい文章だととても心配になってしまいます。しかし日報でそれらを確認することができます。

と、ここまで書いてて、別に手書きである必要は少ないかもなーって思いました。が、やっぱり後輩のためにそうした形跡を残しておき、後から振り返ることができるのは大切です。
stock_value at 19:29|この記事のURLComments(0)TrackBack(0)考え 

2017年03月19日

このエントリーをはてなブックマークに追加
今までUTMという製品については、いまいち意味がわからないというのが正直なところでした。
というのも、アンチウイルスが主たる重要な機能だと思っていましたが、結局のところ各端末でアンチウイルスソフトをインストールするのが重要です。
だから端末とルーターの両方でアンチウイルスを実現する必要はないと考えていました。

しかし最近は事情が異なるように思います。
標的型攻撃といわれるようなものや、C&Cサーバーへの接続など、アンチウイルスソフトの範囲を超えているようなセキュリティ対策が求められています。

本当は、UTMのアンチウイルス機能とクライアントのアンチウイルス機能の併用時にはライセンスが安くなるとか、そういうのがいいのですがなかなかそういうソフトは見つかりません。
少しずつ提案しているのですが、UTMゆえのトラブルも散見されますので、気をつけていきたいと思います。
stock_value at 10:59|この記事のURLComments(0)TrackBack(0)技術 

2017年03月18日

このエントリーをはてなブックマークに追加
僕が管理しているいくつかの linux サーバーですが、いつセットアップされたのか調べたいと思うときがありました。いやこれは完全に個人的な興味なんですが。

で、いくつかの方法を調べたのですが、いまいちよくわからないというのが正直なところです。

以下の方法が確実っぽい?
ファイルシステムの作成日時を確認

・マウントされているデバイスを確認
#df
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 45G 2.0G 41G 5% /
tmpfs 495M 0 495M 0% /dev/shm
/dev/sda1 488M 108M 355M 24% /boot

このなかで /dev/sda3 を作成したのは、インストール時なので作成日を見ればいいようです。

# tune2fs -l /dev/sda3 | grep 'Filesystem created'
Filesystem created: Mon May 6 00:59:29 2013
手元にあるサーバーでは、上記のようになっていました。そしてこれはなんとなく正しいように思います。

キックスタートの cfg ファイルの作成日時
ll /root/anaconda-ks.cfg
-rw-------. 1 root root 1019 5月 6 01:02 2013 /root/anaconda-ks.cfg

これもインストール時に作成されるので、消していなければ正しい値のように思われます。
そして、僕の環境では、上記2つのファイルが近似していました。深夜に作業しているのは不明です。覚えていません。ゴールデンウィークに作業していたんでしょうねw

以下のコマンドでRPMから日時も確認できます。
#rpm -qi basesystem | grep Install
Install Date: 2013年05月06日 01時00分32秒 Build Host: c5b2.bsys.dev.centos.org

ファイルの変更日時から
# stat /* | grep Change | sort
Change: 2013-05-06 00:59:42.137000001 +0900
Change: 2013-05-06 01:00:29.204000000 +0900
Change: 2013-05-06 01:00:32.031000000 +0900
stock_value at 10:19|この記事のURLComments(0)TrackBack(0)技術 

2017年03月17日

このエントリーをはてなブックマークに追加
CentOS 7 にインストールしました。

※インターネットに接続できることや、SELinuxがOFFにすることなどの、基本的な設定はしています。

必要なモジュールのインストール
#yum install perl
#yum install perl-Data-Dumper
#yum install perl-Digest-MD5
#yum install ld-linux.so.2

管理画面を表示させるために、Apacheの導入と、SSLモジュールが必要です。
#yum install httpd
#yum install mod_ssl

カスペルスキーモジュールのインストール
#rpm -ivh klms-8.0.1-721.i386.rpm
→ /opt/kaspersky/klms/bin/klms-setup.pl を実行するように言われる・・・あとで。

#rpm -ivh klms_ja-8.0.1.721-7.noarch.rpm
#rpm -ivh klmsui-8.0.1-721.x86_64.rpm
→ /opt/kaspersky/klmsui/bin/klmsui-setup.pl を実行するように言われる。・・・あとで。


セットアップツールの実行
# /opt/kaspersky/klms/bin/klms-setup.pl

※メモがここまでだったので、後日またちゃんと記事にしたいと思います。


stock_value at 23:03|この記事のURLComments(0)TrackBack(0)技術 

2017年03月16日

このエントリーをはてなブックマークに追加
僕はサーバーを管理することが多く、中のコンテンツについては、あまり興味もありませんし、なにより知識がありません。
今回、 cakephp を動作させているサーバーで作業していました。

httpd.conf の設定も完了し、このときには動作は問題ありませんでした。
Site A
Site B
Site C
バーチャルホストで複数のサイトを振り分け、ログを見る限りではそれぞれに問題無く振り分けられ、また静的なファイルについては、正しく表示されることも確認しました。

そしてコンテンツ管理者が Site A-C に cakephp を設置し動作させたところ、Site Aは正しく表示されるのですが、それ以外のURLはすべて同じようにSiteAが表示されてしまいました。

最初に言われたのは、.htaccess は有効になっていますか?と。もちろん今回の件は htaccess が利用されることを聞いていたので、・・・そしてhtaccessを利用するのはあたりまえだし・・・ 設定は終わらせていました。それに話を聞く限りでは SiteA の cakephp は正しく動作しているようです。

と、このような状態で httpd.conf の各種設定を改めて確認しました。しかしながら僕が確認した範囲ではすべてが正しく動作しているようでした。

ということでまずは基本的な動作確認
1. ログの確認
2. rewrite log の取得
3. cakephp の設定確認

1. ログの確認
VirtualHost で設定している箇所から、ログファイルの場所を確認します。
SiteAや、SiteBにアクセスしたときに http のログファイルが正常に表示され、アクセスされていること、レスポンスが正しいことを確認します。
この確認によって ServerName や ServerAlias の設定が正しいことを確認します。
VirtualHost が複数あって、ServerName などに設定している値が重複していると、上位行が優先されるので、下位行は設定が活きません。
意外とありがちなミスですね。

2. rewrite log の取得
VirtualHost の設定項目に以下のログ取得項目を記載します。 reload も忘れずに。
・・・以前もこのことブログに書いたと思っていたら、やっぱり前回も cakephp 絡みでした
RewriteLog /tmp/rewrite-SiteA.log
RewriteLogLevel 9

これで、 正しいサイトの htaccess が読み込まれていること、意図通りの動作になっていることをを確認します。
そして、上記設定を確認したところ問題ありませんでした。

ここまで確認したところ、やはり conf ファイルは問題なさそうでした。そのため次は cakephp の設定が疑わしくなります。特にSiteAは問題無いので、SiteB-Cですね。

3. cakephp の設定確認
パス定数と変更方法やURLの取得
知識が足りない僕ができることは限られています。DBの接続情報を確認したり、テキストベースで行われている設定ファイルを確認したり。

で、上記参考サイトの通り、cakephp を動作させるパスの設定を確認しました。
webroot/index.php
そしてどうやら以下の APP_DIR に間違いがあることに気づきました。
define('APP_DIR', 'app');

ここを書き換えたところ、SiteA-Cまで問題無く表示されるようになりました。
stock_value at 10:01|この記事のURLComments(0)TrackBack(0)技術