 |
|
|
2018 04,05 00：55 |
|
|
CentOS7から、サービスの起動方法が変わり、なかなかなれない
というより、もはや癖みたいなっており、 いつも「あっ、違った」って思うので、いい加減ここに残す CentOS 6 以前の場合、サービスを自動起動させる、させないといった設定は 「chkconfig」コマンドを使用していたと思います。 CentOS 7ではサービスの管理は一部のサービスを除き「systemd」で行う といった仕様に変更となり、これがなかなか慣れない 従来の「chkconfig サービス名 on | off 」のコマンドも使用でき、 「systemctl」コマンドに転送されるけど、こういうのはちゃんとしておかないとね。 今まで chkconfig httpd on とか、chkconfig httpd off で起動設定をしていました。 chkconfig --list で確認したり。 CentOS7からは、
自動起動設定 systemctl enable httpd.service
自動起動解除 systemctl disable httpd.service
自動起動の一覧確認は、 systemctl list-unit-files -t service これを実行すると分かりますが、 ステータスの意味としては、
表示 設定状況
enable 自動起動設定有効
disable 自動起動設定無効
static 単体では自動起動できないサービス
起動に関しても、/etc/init.d/httpd とかじゃなくて、systemctl start httpd.service
PR |
|
|
|
|
2018 02,01 23：50 |
|
|
とあるサイトから
世界で30%以上のシェアを占めるシマンテック系のSSLサーバー証明書が、 2018年3月と10月に、段階的に無効扱いされるようになります。 ベリサイン／シマンテック系のSSL/TLSサーバー証明書が、次のスケジュールで無効化されることが、すでに決まっています。
対象のサーバー証明書の発行元：
Symantec
GeoTrust
RapidSSL
Thawte
無効化スケジュール：
2018年3月15日ごろ： Chrome 66のベータ版で、上記発行元が2016年6月1日より前に発行した証明書を信頼しないようになる
2018年4月17日ごろ： Chrome 66の通常版で、上記発行元が2016年6月1日より前に発行した証明書を信頼しないようになる
2018年9月13日ごろ： Chrome 70のベータ版で、上記発行元が発行した証明書すべてを信頼しないようになる
2018年10月23日ごろ： Chrome 70通常版で、上記発行元が発行した証明書すべてを信頼しないようになる
上記の対象となるSSLサーバー証明書を使っているサイトは、証明書の期限がもっと先まで有効だったとしても、ブラウザ側で正当な証明書を使っているとみなされなくなります（つまりHTTPSではなくなる）。
上記はGoogle Chromeでの予定ですが、Firefoxも同様のタイミングで同じように対応していくことを発表しています（IE・Edge・Safariなどは未定）。
無効化にあたる背景として、証明書発行の信頼性に対するグーグルの指摘です。 無効化の対象となる証明書を、DigiCertの新たな認証ポリシーに準拠した新たな証明書に置き換える手続きを進めています。 サーバー証明書は利用企業のWebサーバーにインストールして利用する仕組みのため、利用企業側が新しい証明書を発行して入れ替える作業をしなければいけません。 そのためDigiCertでは、すべての利用企業に対して連絡をとっているとのことです。 ただし、DigiCert側が連絡をとれるのは、証明書発行の手続きをした連絡先だけです。そのため、担当者が退職していたり、事情を知らなかったり、メールを見逃していたり、伝達漏れがあったりした場合、証明書の差し替えが必要なのに適切に行われない可能性があります。 再発行は（同じ有効期限ならば）無料で行うとのことです
|
|
|
|
|
2018 01,10 22：08 |
|
|
ずっとどうやってやるんだろう？って思っていた方法を知ったので、
ここに残す fail2ban-client set jail名 unbanip ***.****.***.***（BANを喰らって繋がらなくなったIP） 「jail名」はjail.conf内に記載した名称を記載 また、fail2banでWEBの不正アタックを防ぐも記載されていたので、 それはこちらを参考に http://chee-s.net/fail2ban%E3%81%A7wordpess%E3%81%B8%E3%81%AE%E4%B8%8D%E6%AD%A3%E3%82%A2%E3%82%BF%E3%83%83%E3%82%AF%E3%82%92%E9%98%B2%E3%81%90
|
|
|
|
|
2017 12,28 14：07 |
|
|
年末なので、日付を変更して、プログラムが期待通りに動作するか
確認するために、VBox上のCentOS7で、日付を変更して、テスト
しかし、日付を変更しても、すぐに現在日時に戻るという現象
OSが壊れたか？と思い、軽く急いでいたので仕方なしにシェルで、
日時変更コマンドを無限ループで叩くという荒業でテスト
時間ができたので、その原因を調べてみたら、
どうやら、VBoxが悪さをしていた様子。
デフォルトでは、VirtualBox のゲスト OS の時刻をホスト OSと同期しているようです。
マジか。。。
別に同期しなくてもよくね？
なので、その同期を切らないと、ゲストOS（CentOS7）で変更しても、
同期がかかり、戻されるという、リアルな無限ループ
コマンドプロンプトを起動して、VirtualBoxがインストールされているディレクトリへ移動
僕の場合は、C:\Program Files\Oracle\VirtualBox なので、
cd C:\Program Files\Oracle\VirtualBox
同期をさせたくない場合は、以下のコマンドを実行
VBoxManage setextradata "VM name" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 1
同期をさせたいときは、こっちのコマンドを実行
VBoxManage setextradata "VM name" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 0
VM name は、それぞれ設定した名前を記述
この情報を探すのに、苦労をしました。。。
参考：https://digitalbox.jp/virtualbox-guest-sync-time-host/
|
|
|
|
|
2017 12,21 11：19 |
|
|
pythonのバージョンを強引にあげたら、yumが使えなくなった。。。
yumはpythonスクリプトらしいので、バージョンが変わると動かなくなるらしいです。
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
No module named yum
・・・・
こんな感じに。
なので、また強引に古いバージョンを復元させて、yumのconfigに
古いバージョンのpythonで実行をしてあげるようにする必要がある。
（古いpythonは上書きしちゃったから、別のサーバから持ってくるという強引さ）
# vi /usr/bin/yum
#!/usr/bin/python
import sys
を、
#!/usr/bin/python2.6.6
import sys
と指定。
はい、yum 復活。
ちゃんと、バージョンの切り替えツールみたいのも入れたら、
こんなことにはならなかったのかもしれないです。
|
|
| 忍者ブログ [PR] |
