洗濯乾燥機の乾燥機能のメンテナンスについて

ヒートポンプ式洗濯乾燥機をお使いで、保証期限がまだ残っている方へのTips(?)です。

乾燥機能付き洗濯機は、その構造上(取扱説明書の通りのお手入れをしていても)(診断機能がエラーを吐いていなくても)ヒートポンプユニットへの埃や黴や洗剤滓の目詰まりが避けられないような気がします。

最近、乾燥時間が延びたかなぁ、と思われた方は、保守契約先へのメンテナンスの相談をされた方が良いと思います。

ユニット洗浄や交換について、良い結果になると良いですね。

保証が切れたあとの交換は、かなりおサイフに痛いですから…。

権限が無いために操作出来ないネットワークドライブ上のオブジェクトを操作したいとき

SMBなCIFSネットワークドライブ上のオブジェクトに対し、ユーザが(管理者を含む他人から見えないものを作ろうとしたりして)権限を弄ぶと、ドメイン管理者側からの操作が出来なくなってしまいます。
こうなると、サーバ移転の時などに大変困る事になります。
このような時の回避策を以下に記します。
takeownやicaclsでの対応が出来ない/処理時間が掛かり過ぎる場合に、駄目元で試してみて下さい。

  1. emcacl.exeを入手する
    EMCストレージ上のCIFSオブジェクトに対してのACL操作ユーティリティです。
    本来EMCのストレージ用ですので、以後は自己責任でお願いします。
    当該ファイルは『CifsTools_ほげほげ.zip』に含まれています。
    DELL EMCの営業さんにお願いするか、DELL EMCのサポートサイト https://support.emc.com/ に登録すると幸せになれるかも知れません。
  2. DomainAdminsグループ権限でログインする
  3. 管理者権限でコマンドプロンプトを開く
  4. DomainAdmins権限を当該オブジェクトに追加する
    emcacl path_to_target /T /E /C /Y /G "Domain Admins@mydomain:F"

emcaclのオプション

オプション 意味
/T 再帰処理
/E ACL編集
/C エラーが出ても継続
/Y 確認無しで実行
/G user:perm 指定されたパーミッションのユーザを追加
perm:
 R Read
 C Change(write)
 F Full control
 P Change Permissions
 O Take Ownership
 X EXecute
 E REad
 W Write
 D Delete
/LOG:path ログファイル(新規作成)
/LOG+:path ログファイル(追記)
/U ログファイルの文字コードをUTF-8に
/R user 指定ユーザをACLリストから削除
/P user:perm  指定ユーザのパーミッション書き換え
permの内容は/Gと同じ
/D user  指定ユーザを拒否モードで追加

ダイソンコードレス掃除機のお手入れについて

我が家ではここ数世代、ダイソンの掃除機を使っていたのですが、先日コードレスタイプ(Cyclone V10 Fluffy)にリプレースしました。


dyson Cyclone V10 Fluffy

この製品ですが、キャニスタータイプと比べると、サイクロン部分でのゴミの分離よりもフィルター部分の負荷が高いのですね…。

フィルターお知らせライトが点滅するよりも前に、フィルターの詰まりで効率が下がってしまうようです。

説明書的には水洗いなのですが、時間がかかるし乾くまで使えないし…、ということで、このエアーダスターの出番です。


サンワサプライ CD-32SETN

いままでいくつかのメーカーのいくつかの製品を使っていますが、これは結構強力で気に入っています。

使用法のコツですが、0.3秒程度の時間でのプッシュを複数回に分けて、フィルター表面と内部の埃を飛ばして下さい。

連続で噴射してしまうと、すぐにガス圧が下がってヘロヘロになってしまいます(この手の製品は全て同じ性質を持っています)。

吹く方向は、円筒内部から外部に向けて、となります。

KUSANAGI環境移行後に不具合が発生した場合

アフィリエイト関係を行っている場合、サイトの高速化のために

kusanagi bcache on
kusanagi fcache on

を行っていると、合わない場合があるかも知れません(kusanagiのせいではなく、アフィリエイト側の問題ですが)。

この他に、

  • カテゴリの新規登録/カテゴリ割り付けなどが出来なくなる
  • テーマ編集が出来なくなる
  • CSSエディタが動かなくなる

等となった場合、

kusanagi waf on

としていないか確認してみて下さい。

WordPressサイトをKUSANAGIに移行するテスト

今まで使っていたサイトの反応が遅くなって来ており、編集中に(外部からアクセスして下さっている方に)5xxエラーが時々出るようになったため、テスト用のIPアドレスとFQDNを準備し、KUSANAGIへの移行手順テストを先日行いました(これを受けて、6/21に本番移行しています)。

基本的な手順は、『ぼっちサーファーのブログ 複数のWordPressをKUSANAGI for さくらのVPSに移行する手順 まとめ』を参考にしています。
※2019年06月時点での情報となります

事前に用意する物

  • https://import.wp-migration.com/all-in-one-wp-migration-file-extension.zip
    コンテンツの移行に使いますので、予めダウンロードしておいて下さい。
  • kusanagiユーザー用のパスワード
  • MySQL(MariaDB)のrootパスワード
  • 既設WowdPress実行環境のPHPバージョン
    可能な限り、既設WowdPress実行環境のPHPは7.2に上げておいて下さい
  • データベース名
    仮の物でも構いませんが、本番と同じ名前でも構いません
  • データベースのユーザー名
    仮の物でも構いませんが、本番と同じ名前でも構いません
  • データベースユーザーのパスワード
    仮の物でも構いませんが、本番と同じ名前でも構いません
  • WordPressユーザー名
    仮の物でも構いませんが、本番と同じ名前でも構いません
  • WordPressユーザーのパスワード
    仮の物でも構いませんが、本番と同じ名前でも構いません
  • 移行対象サイト名(FQDN)
  • プロファイル名
    何でも可
  • テスト用のサイト名
    移行対象サイトとは別なFQDN
  • テスト用サイトのIPアドレス
    移行対象サイトとは別なアドレス
    DNSにも正引き登録しておいて下さい
  • 移行対象サイトのフルバックアップ
    プラグイン『All-in-One WP Migration』をインストールし、有効化、エクスポートして手元にダウンロードしておいて下さい
  • SSL証明書登録用のメールアドレス

環境作成

root環境で行います。

公式の手順に従い、適当なサービス上に環境を展開しておきます。
https://kusanagi.tokyo/cloud/

OSの初期設定

タイムゾーンがJSTでない場合

timedatectl set-timezone Asia/Tokyo

swap領域が取られていない場合(freeコマンドで確認)

dd if=/dev/zero of=/swapfile bs=1M count=4096
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo "/swapfile swap swap defaults 0 0" >> /etc/fstab

KUSANAGIの初期設定

yum --enablerepo=remi,remi-php56 update -y
reboot
kusanagi init --tz tokyo --lang ja --keyboard ja --passwd 'kusanagiユーザーのパスワード' --nophrase --dbrootpass 'MySQL(MariaDB)のrootパスワード' --nginx --ruby24 --dbsystem mariadb
# 途中でPHPのバージョンを聞かれますので答えて下さい

KUSANAGIのプロビジョニング

  • hostsでサイト名をテスト用サイトのIPアドレスにリダイレクトさせます
    例として、移行前のサイト名をfoo.bar.com、テスト用のIPアドレスを123.123.123.123とします
    # C:\Windows\System32\drivers\etc\hostsに追加
    foo.bar.com 123.123.123.123
  • (出来れば)ブラウザのクッキーやキャッシュを削除します
  • kisanagiのプロビジョニングを行います
    kusanagi provision --WordPress --wplang ja --fqdn サイト名(FQDN) --noemail --dbname データベース名 --dbuser データベースのユーザー名 --dbpass 'データベースユーザーのパスワード' プロファイル名
  • ブラウザで移行対象サイトに接続し、WordPressの初期設定を行います
    各パラメータは事前に決めておいた物を入れておいて下さい
    テーブル接頭辞はそのままで構いません

データ移行

  • wp-config.phpにFTPパスワードを設定します
    vi /home/kusanagi/プロファイル名/DocumentRoot/wp-config.php
    # #define('FTP_PASS','*****');
    # ↓
    define('FTP_PASS','kusanagiユーザー用のパスワード');
  • プラグイン『All-in-One WP Migration』をインストール→有効化
  • ダウンロードしておいたall-in-one-wp-migration-file-extension.zipをプラグインとしてアップロード→インストール→有効化
  • cd /home/kusanagi/プロファイル名
    chmod 777 -R DocumentRoot
  • All-in-One WP Migrationでデータをインポートします
    インポート完了時に、『パーマリンク構造を保存する』をクリックします
    変更を保存をクリックします(設定の保存が行われます)
    変更を保存をクリックします(パーマリンク構造の更新が実行されます)
    ※認証画面に差し戻された場合、再度認証して下さい
    ※どうしても駄目なときは、次のサイトFQDN変更ののち、パーマリンク構造を元のサイトのものに合わせて下さい

サイトのFQDNを変更

kusanagi setting --fqdn テスト用のサイト名 プロファイル名
kusanagi ssl --https noredirect プロファイル名
# 次の2行は(kusanagi setting で変更済みの筈ですが)念のため
wp search-replace 'http://サイト名' 'http://テスト用のサイト名' --path=/home/kusanagi/プロファイル名/DocumentRoot/
wp search-replace 'https://サイト名' 'https://テスト用のサイト名' --path=/home/kusanagi/プロファイル名/DocumentRoot/

アクセステスト

  • hostsのリダイレクト設定を削除します
  • ブラウザからテスト用サイト名でアクセステスト

SSL証明書の設定

kusanagi ssl --email SSL証明書登録用のメールアドレス プロファイル名
kusanagi ssl --https redirect プロファイル名

セキュリティ警告への対応

cd /home/kusanagi/プロファイル名
chmod 440 DocumentRoot/wp-config.php
chown kusanagi:www DocumentRoot/wp-config.php
chmod -R 755 DocumentRoot/wp-content
mv DocumentRoot/wp-config.php ./

firewalldが動いていてsshを違うポートに変更する場合

# sshの待ち受けを22/tcpから12345/tcpに変更
# /etc/ssh/sshd_config は変更済で、sshdはリロード済みなこと
# 定義の確認
firewall-cmd --info-service=ssh
# 12345/tcp追加
firewall-cmd --permanent --service=ssh --add-port=12345/tcp
# 定義読み込み
firewall-cmd --reload
# 定義の確認
firewall-cmd --info-service=ssh
# 22/tcp削除
firewall-cmd --permanent --service=ssh --remove-port=22/tcp
# 定義読み込み
firewall-cmd --reload
# 定義の確認
firewall-cmd --info-service=ssh