apt-get updateに異常に時間がかかる場合の対処法

Ubuntu 16.04LTSのapt-get updateに異常に時間がかかるので調べてみると、どうもIPv6周りの挙動に問題があるらしい。

apt-get -o Acquire::ForceIPv4=true update

上記のようにコマンドラインオプションを指定すると、強制的にIPv4を使用して接続させることが出来る。
私もこれで問題が解決した。

だがしかし、私は忘れっぽい性格なので、毎度コマンドライのプションを指定するというのは頂けない。
その場合は「/etc/apt/apt.conf.d/99force-ipv4」と言うファイルを新規に作成し、ファイルに下記の内容を記載する。

Acquire::ForceIPv4 "true";

これで都度オプションを指定せずとも、毎回IPv4を使用して動作するようになる。

参考:Force Apt-Get to IPv4 or IPv6 on Ubuntu or Debian

nginxでhttp/2(SPDY)を有効にする

サーバーが欧州にある事もあってnginxのキャッシュが機能していても結構遅い。そこでhttp/2に対応することにしました。nginxでhttp/2を有効にするのはとっても簡単。

server {
  listen 443;
  ...
}

上のlistenを、下のように書き換えるだけ。

server {
  listen 443 ssl http2;
  ...
}

その後「sudo service nginx restart」でnginxを再起動すればhttp/2が有効になります。たったこれだけなのに、今までhttp/2を有効にしていなかったとか・・・orz

http/2が有効になったことで、ページの表示完了までにかかる時間が半分以下になりました。

letsencrypt renewでunexpected error: ‘server’が発生する

常時SSLを実現するためにLetsEncryptを使用しています。サーバーの移行に伴い、旧サーバーから/etc/letsencrypt以下のファイルをシンボリックリンクも含めてすべて複製していました。問題なく動作していそうなので安心していたのですが、証明書を更新しようとすると以下のようなエラーが発生してしまいます。

~$ sudo letsencrypt renew
Processing /etc/letsencrypt/renewal/www.example.net.conf
2017-10-25 03:17:34,835:WARNING:letsencrypt.cli:Attempting to renew cert from /etc/letsencrypt/renewal/www.example.net.conf produced an unexpected error: 'server'. Skipping.

設定ファイル(www.example.net.conf)の記述内容が古いバージョンのものであることが原因のようです。/etc/letsencrypt/renewal/www.example.net.confを編集し、serverパラメータを追加します。

# Options and defaults used in the renewal process
[renewalparams]
#・・・
server = https://acme-v01.api.letsencrypt.org/directory
#・・・

[[webroot_map]]
www.example.net = /var/www

その後、あらためて「–force-renew」オプションを付けて証明書の更新をおこないます。

~$ sudo letsencrypt renew --force-renew
Processing /etc/letsencrypt/renewal/www.code-lab.net.conf
new certificate deployed without reload, fullchain is /etc/letsencrypt/live/www.code-lab.net/fullchain.pem

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/www.code-lab.net/fullchain.pem (success)

となり証明書の更新に成功しました。www.example.net.confの内容も、先ほど追記した1行以外にも大幅に書き換えられて、新しいバージョンに適合する物に更新されたようです。

参考:Fix Lets Encrypt renewal error on Ubuntu 16.04

Ubuntu 16.xでUFWを有効にする

ufw(Uncomplicated FireWall)はFiewwallソフトです。ScaleWayのSecurity Groupではデフォルトの設定を接続不可にすることができないので、安全に使用するためには別途irewallを設定することが必須です。Linuxで標準的に使われるiptablesでもよいのですが、iptablesは設定が煩雑なので、シンプルで分かりやすいufwを使うことにします。

sudo apt-get install ufw
sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw default DENY
sudo ufw enable

sudo ufw enableを実行するとFirewallが有効になります。sshなどを許可しないままFirewallを有効にすると、完全にハマるので気を付けましょう。

sudo iptables -L

上記コマンドを実行すると、ufwによってiptablesがどのように設定されているか確認できます。

参考:Ubuntuのソフトウェアファイアウォール:UFWの利用

WSUSに追加したWin10でWindowsUpdateがエラー(0x80244019)になる

Windows 2012R2のWSUS環境でクライアントにWindows10を追加し、Windows10でWindowsUpdateを実行するとエラーコード:0x80244019が出て失敗する場合がある。

Windows10移行はUpdateFileの配信にesd形式のファイルを使うように変更されている。WSUSサーバーのIISで、MIME設定にesd形式の拡張子が登録されていないためにダウンロード出来ないのが原因。

IISマネージャーを開き、WSUSの管理にあるMIMEの種類から拡張子.esd、MIMEの種類application/octet-streamを追加する事で解決する。

WSUSに追加したWin10でWindowsUpdateがエラー(0x8024401C)になる

Windows 2012R2のWSUS環境でクライアントにWindows10を追加し、Windows10上でWindowsUpdateをしたところ、にエラーコード:0x8024401Cが出て失敗する場合がある。

サーバー側の状態をタスクマネージャなどで確認すると、Windows10でWindows Updateを実行した直後からCPU負荷が上がったままになっていることが分かる。この場合の原因はWSUSサーバー側の処理に時間がかかり、途中でIISのセッションが切れてしまうことによる。

またWindows10のUpdateファイルは拡張子.esdのファイルで提供されている。初期状態だとMIMEの設定にesdファイルが含まれていないために、Updateファイルをダウンロード出来ずにエラーとなる。

IISマネージャを起動してアプリケーションプールからWsusPoolを開き、CPUの制限間隔を5分から15分程度に変更する。また、全般のキューの長さも10000から25000程度に拡張する。リサイクルのプライベートメモリ制限を18342456から0にして制限を解除します。

Powershellでパスワードを指定して共有ドライブをマウントする

PowerShellからパソコンの共有ドライブをユーザーIDとパスワードを指定してマウントします。

$computerName = '192.168.1.1'; # 接続先クライアントのIPアドレス
$adminPass = 'password'; # 接続時に使用するパスワード
$adminUser = 'admin'; # 接続時に使用するユーザーアカウント

# 認証情報のインスタンスを生成する
$securePass = ConvertTo-SecureString $adminPass -AsPlainText -Force;
$cred = New-Object System.Management.Automation.PSCredential "$computerName\$adminUser", $securePass;

# 共有ドライブをBドライブとしてマウントします
New-PSDrive -Name 'B' -PSProvider FileSystem -Root "\\$computerName\C`$" -Credential $cred;

# --- ここで色々処理

# Bドライブをマウント解除します
Remove-PSDrive -Name 'B';

ちなみにC$はWindowsでデフォルトで作成される共有名です。管理者権限を持つユーザーでしか開けませんが、C:ドライブ全体へのフルアクセスになっています。ここをマウントしてゴニョゴニョできると、クライアントパソコンの諸々の管理や情報収集が捗ります。

Windowsで管理者権限のユーザーアカウントにパスワード設定しないのが論外な理由は、こういう所にある。

ActiveDirectory(以下AD)を導入してたら、ADの管理者アカウントでプロセスを走らせれば、認証情報作ル必要も無くなります。New-PSDriveすら必要なく「\\192.168.1.1\c$」でアクセス出来るので、こんなKnow Howいらないんだけどね。

原因不明のPCトラブルにあった場合の対処

コメントにトラブルの問合せとかくるようになったので、トラブル対処の一般的なことを述べておく。
まずは再インストールを検討しよう。それが駄目なら新しく買い足そう。

僕みたいに「趣味」でトラブルシューティングする場合でも、放置できるトラブルなら好きなだけ時間を掛けて調べる、放置できないなら再インストールなり予備機移行なりをした後に、調べるって事になる。再インストールは重要な選択肢なのだ。

1.まずは時間を決めて情報収集する

1時間とか、2時間とか時間を決めて、対処法がないか情報収集をします。
無闇に時間をかけて調べてはいけません。もしかしたらすぐに対処法が見つかって、若干の設定変更等で対処できるなら、10分ほどで解決するかもしれません。ですが何日かけても、対処法が見つからないかもしれません。
存在するか分からない情報を探すというのは、リスク(不確実性)の高い方法です。だから最初にどの程度の時間(損失)をかけて情報収集を試みるのか、しっかり考えておくことが大事です。

2.OSの再インストールを検討する

OSの再インストールは時間はかかりますが、リスク(不確実性)の少ない良い方法です。「ハードウェアの故障」「仕様上から出来ない事(バイ・デザイン)」「再現性のあるソフトウェアの不具合(バグ)」のいずれかでも無い限り解決します。

2.1.ハードウェアの故障有無を判断する

メーカー製パソコンだと自己診断機能を備えていることが多いです。付属のマニュアルなどを確認して、自己診断を実行して下さい。
自作パソコンだと自己診断機能という訳には行きません。イベントログの内容を精査したり、memtest86やCrystalDiskInfo等のフリーウェアを使ったり、あるいは目視や動作音から判断していくことになります。

2.2.データのバックアップ状態を確認する

あらためてバックアップする必要のあるデータが無いか検討します。普段からバックアップを取っていないとこういう時に困ります。昔は外付けのHDDにコピーしたり、DVDに焼いたりと作業が発生していたので面倒でしたが、今ならOneDriveやGoogleDriveと同期すると言う方法もあるので、こまめにバックアップ(複製)を取るようにしようね。
WEBブラウザのお気に入りとか、普段使用しているサービスのユーザーIDとパスワードとか、バックアップを忘れがちなので気をつけよう。

2.3.再インストールに必要な物を確認

後は付属マニュアルなどにそってひたすらインストールするだけなのだが、インストールメディアがないとか、PIDが分からないとかありがちである。気をつけよう。

3.検討した結果、今すぐの再インストールは無理だと思ったら

予備のパソコンを使おう。
もし予備のパソコンが使えないなら、新しいパソコンを買ってこよう。もちろん本気である。

トラブルの状況にもよるが、パソコンが起動しない状態でHDDからデータをバックアップするには別のパソコンが必要になる。情報収集しようにも、やはり別のパソコンがないと効率が悪い。再インストール作業には2日~3日かかることもあるが、この時間的損失を許容できないなら、その間は別のパソコンを使う以外にない。トラブルの発生しているパソコンの復旧作業は、手が空いたときにしよう。
借りるって手もよさそうに思うが、有料のレンタルは決して安くないし、機材の手配やデータ移行、環境設定やら何やらを考えると結局は2日~3日かかってしまう。量販店で買うなら、1時間後には手元にパソコンが届くだろうし、1日あればなんとかなる。

4.再インストールしても駄目なら・・・

「ハードウェアの故障」「仕様上から出来ない事(バイ・デザイン)」「再現性のあるソフトウェアの不具合(バグ)」のいずれかって事になる。ここまで来たなら、メーカーサポートを頼った方が良い。

AD環境でクライアントPCの名前解決に失敗する

Active Directory環境下でクライアントパソコンの名前解決を行うと実際とは異なるIPアドレス帰ってくる場合、DNSのキャッシュしている情報が不整合を起こしています。

その場合はADサーバー上において管理ツールの「DNSマネージャー」を起動して、前方参照ゾーンを開き、表示されるコンピューター名の一覧から当該クライアントパソコンの設定を削除します。

削除した分のデータはクライアントパソコンを再起動したときに、正しい内容で再作成されます。

Officeのタイトルバーに表示されるユーザー名をAD環境下で変更するには

Office 2013以降はタイトルバーの右上にユーザー名が表示されています。ここに表示されているユーザー名はOneDriveのユーザー名であったり、ActiveDirectory(以下AD)のユーザー名であったり環境によって異なります。ところがAD環境下の場合にはADサーバ側でユーザーの登録内容を変更しても、Officeのタイトルバーに表示されている氏名には反映されません。

AD以外の環境・・・例えばOneDriveのユーザー名ならばファイルメニューのアカウントを開き、サインアウトを実施します。その後にあらためてファイルメニューのアカウントを開き、サインインする事でOneDriveのユーザー名を反映することが出来ます。ですが、Active Directory環境下の場合には、ファイルメニューのアカウントからサインアウトを選択するとサインアウトできますが、もう一度ファイルメニューのアカウントからログインし直すことが出来ない為に、ログアウトしたままになってしまいます。

Active Directory環境下の場合にはレジストリを直接編集して名前を変更する必要があります。レジストリエディタを起動して「HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Identity\Identities」を開きます。ここにADユーザアカウント名でフォルダが作成されていますので、「FriendlyName」および「Initials」を変更します。この後Officeを起動すると、新しい名前が反映されるようになります。

参考:https://technet.microsoft.com/en-us/library/jj683102.aspx#Bkmk_4_DeleteCreds