100均のUSBアダプタで、ジャンクハブを修理してみた。

100均で売っている、自称5V2AなUSBアダプタを使っていたのですが、
中からカラカラと音がするようになって、危険と判断し分解、結果中でプラスティックが折れた？？のか破片が出てきただけでした。
これはこれで、何かに流用できないかと、電源部が壊れたジャンクハブの電源ユニットとして流用してみました。

 

100Vが流れる箇所は念入りにホットボンドで絶縁、補強しておきます。

電源との接続はUSBケーブルをぶった切って流用しました。

電源が壊れた時交換が楽なようにｗ

 

無事復活しました。

Ubuntu 16.04でアップデートに失敗する

自宅にあるSoftEtherなUbuntu 16.04をアップデートしたら、以下のようなメッセージが出て失敗しました。

update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
insserv: warning: script 'S20vpnserver' missing LSB tags and overrides
insserv: warning: script 'vpnserver' missing LSB tags and overrides
insserv: There is a loop between service plymouth and mountdevsubfs if started
insserv:  loop involving service mountdevsubfs at depth 2
insserv:  loop involving service udev at depth 1
insserv: There is a loop at service plymouth if started
insserv: Starting vpnserver depends on plymouth and therefore on system facility `$all' which can not be true!
insserv: Starting vpnserver depends on plymouth and therefore on system facility `$all' which can not be true!
insserv: Starting vpnserver depends on plymouth and therefore on system facility `$all' which can not be true!
以下続く・・・

どうやら原因はsystemd周り？のようで、対処法は

起動スクリプトの

# chkconfig: 2345 99 01
# description: SoftEther VPN Server

なところを

# Provides : vpnserver
# Required-Start :
# Required-Stop :
# Default-Start : 2 3 4 5
# Degault-Stop : 0 1 6
# Description : SoftEther VPN Server

にすればOKです。

早速WiKiに反映しておこう・・・

ジャンクPoEハブを修理してみた

某所の勉強会に参加ついでに、今時100MなジャンクPoEハブを入手しました。
いやまぁ今時100Mなハブなんて正直ジャンクでも買わないのですが、PoEの中身気になったので。
一般家庭なんでPoEな機器はないんですけどね。

 

まずはサクッとばらしてみます。

上の基板がPoEなもののようです。

隣に巨大な電源が占有してます。これはPoE用の電源で、本体重量の大部分を占めるものです。ハブ本体の電源はその上にチョコンと載っているオマケみたいな3.3V電源でした。

 電源を見ますと、予想通りコンデンサがパンクしてます。

手持ちのものとサクッと交換しておきます。

ついでに基板を見ていきます。

PoEの基板は通常のハブの基板に亀の子で乗っかるようになっており、普通のハブにPoE機能を付与できるようになっています。

またこの基板にはACアダプタが接続できるようなパターンもあり、そのような用途にも使用できるよう、汎用的に作られているようです。

ところで、未使用なポート用にダイオードだけは実装されているのは何ででしょう？？

 

下側にあるハブ本体です。

ただのスイッチングハブにしてはやたらチップが多いので、L2レベルの機能はありそうです。

 

コンデンサ張替えで無事直ったので、基板上にシリアル通信できそうな口があったのでつないでみました。

何かがコンソールに表示されるのですが、通信速度が分からず断念。

 

とりあえず、通常のハブとしては機能しました。

Windows Server 2012 R2上のHyper-Vにて、Windows Serverバックアップが失敗する

Windows Server 2012 R2上のHyper-Vにて、CentOS6な仮想マシンを動かしている場合、
WindowsServerバックアップで謎のエラーが発生し失敗することがあります。
（なお、Ubuntu16.04は問題ない）

バックアップに成功しましたが、スナップショット内でバックアップ済みの一部のコンポーネントに不整合があります。このコンポーネントが属しているアプリケーションは、このバックアップが回復に使用された後で正しく機能しなくなる可能性があります。

どうも仮想マシンのバックアップを取るのにVSSを使っているようですが、
これがCentOS6な仮想マシンだとVSSが失敗するようです。
で、解決法は、CentOS6内にHyper-V用のVSSデーモンをインストールします。

yum install hyperv-daemons

トラブルだらけでもう疲れたよ・・・

Windows 10で回復ドライブからリカバリ後回復パテーションが見える

回復ドライブから無事リカバリできたかと思えば、まぁそう簡単にはいかないのがWindows…
今度はなぜか非表示のはずの回復パテーションが見えている（汗
しかも、ディスクの管理からはアクティブパテーションとなっており、回復パテーションと認識すらされていない・・
大丈夫か？Windows10

という訳で直します。
まずはwindowsキー＋Xでコマンドプロンプト（管理者）を実行します。
次にdiskpartを実行します。
select disk 0で０番目のディスクを選択。
list partitionでパテーションを確認。回復パテーションがある番号を確認します。
ここでは３番目にあるとします。
select partition 3でパテーションを選択し
set id = 27
で回復パテーションIDを書き込みます。（これはMBRの話して、UEFIの場合は違うようです。詳しくはここを参照） removeで割り当てられたドライブレターを削除し、exitで終了です。

再起動しても非表示のままであればOKです。

Windows 10 で回復ドライブからSSDへリカバリできない。

Windows 10がプリインストールされたノートPCを購入したのですが、さっそく安全のため回復ドライブを作成後、SSDへ換装し、リカバリを試みましたが、
SSDのほうが容量が小さいため、リストア時

システムドライブが小さすぎます

というエラーが出てリストアできません。クソが
リカバリディスクが付属しない昨今、異なる容量のディスクにリカバリできないのはかなり問題です。
公式DVDイメージをDLしてもライセンスキーが通るかも不明ですし・・・

とググるとドスパラさんの例が出ました。
しかし、試したところ効果なし。
回復ドライブ自体８GBで足りているので、展開できないわけではないはず。
という事はどこかでサイズを覚えているのだろう。と当たりをつけて、回復USBを漁ったところ、
sources\$PBR_ResetConfig.xmlを発見。
この中に
    <MinSize>289982</MinSize>
とあったので、10240とか適当に小さくしてみると、無事動きました。

なお、
sources\$PBR_Diskpart.txtにある
shrink minimum=1000
に設定すると、回復パテーションが１GBで作成されます。
デフォルトだと容量が小さすぎて、複数の回復パテーションが出来ることがあるそうですので、大きくしておきます。

これがわかるまで丸二日つぶしました・・・Orz

Windows Server 2012 R2でWindows Server バックアップをNASにすると失敗する

Windows Server 2012 R2でWindows Server バックアップを利用し、NAS（TeraStation)へバックアップを取ろうとしたところ、以下のようなエラーがイベントログに記録されただけで、とくにダイアログも出ず、黙って失敗していました。

次のエラー コード '0xC03A0005' (このバージョンでは、このファイル形式のバージョンはサポートされません。) のため失敗しました。イベントの詳細で解決策を確認し、問題の解決後にバックアップ操作を再実行してください。

ググってもいまいちピンとこないものばかりなのですが、どうやらバックアップ取得先のNASがLinux系で、Sambaで動作している場合その記録方式によってはエラーになるようです。参考

対応方法は、NASのバックアップ先共有ディレクトリのsmb.confに次の設定を追記します。

strict allocate = yes

といっても、TeraStationは/etc/samba/smb.confに追加しても、再起動時設定を作り変えているようで消えてしまいます。
なので、Web画面で共有ディレクトリの操作をする際に気を付ける。という事で、
自分はバックアップ先共有ディレクトリを一番最後に追加し、設定が自動生成された後に設定を追記するように細工しました。

具体的には、

/etc/init.d/smb.sh
configure()
{
        ## configure files from Buffalo parameters.
        echo "configure samba"
        touch /etc/printcap
        /usr/local/sbin/nas_configgen -c samba
        if [ $? -ne 0 ]; then
                echo "$0 configure fail"
                exit 1
        fi
        echo "strict allocate = yes" >> /etc/samba/smb.conf #追記
}

これで、/etc/samba/smb.cnfの最後に設定が追記されます。

翻訳プロジェクトに参加してみた

これは、すごい広島229の最中に書いています。

英語の勉強もかねて、OSSの翻訳プロジェクトに参加してみました。

今回自分が参加したのはGLPI Project - accounts pluginです。

まぁ自分が使っていて、日本語翻訳がなく、かつ文量が多くなさそうなやつをチョイスしただけですが（汗

ここでは、翻訳プロジェクトとして、transifexを利用していますので、まずはそこに登録します。

 登録が完了しましたら、参加したいプロジェクトに参加依頼を出します。
が、自分は日本語翻訳がなかったので、まずは日本語翻訳を追加する依頼を出します。








プロジェクトの人から承認を受けたら、参加依頼を出します。
こちらも承認を得たら、晴れて参加となります。

プロジェクトに参加したら、翻訳をします。




こんな感じで、左側に原文、右側に訳文を入れていきます。

翻訳文を入れていったら、TABを押すことで保存と次の訳文へ移動します。


保存された訳文は自動的にレビューに回されるようです。

少しでもOSSに貢献できれば。（と自身のスキルアップになれば・・・）

SoftEtherでOpenVPNがつながらない

SoftEtherはOpenVPN互換の機能を持っているのですが、
これに、vpnux clientからつなぐとエラーとなり繋がりません。
なお、マネージメントソフトからDLできるConfをOpenVPNに突っ込むとまぁ当然ですが動くので、vpnux client側の問題になります。

例えば、SoftEtherにvpnux clientからつなぐと次のようなエラーが出て繋がらなかったり、
繋がっても再接続を繰り返したりします。

TLS Error: reading acknowledgement record from packet
Bad LZO decompression header byte: 69

この場合、以下のように接続プロファイルのLZO圧縮を有効にするのチェックを外します。

また、デフォルトの設定だと、次のような警告を目にするかもしれません。

WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).

どうもデフォルトではAES-128-CBCで繋ぎに行くようなので、AES-256-CBCに変えておきます。

一見押せそうにない、グレーアウトした詳細設定をクリックします。

暗号アルゴリズムの設定があるので、ここで設定します。

なお、CA証明書ですが、マネージメントソフトからDLできるConf(L3のほう)にある、

# The certificate file of the destination VPN Server.

にある証明書の-----BEGIN CERTIFICATE-----を含めた行から-----END CERTIFICATE-----を含んだ行までを

な感じで張り付ければOKです。

あと、一部クライアントソフト(説明ではiOS版OpenVPNクライアント)などは、ユーザID、PW認証ではなく、証明書を要求するものがあるようです。

その場合は、

# The client certificate file (dummy).

のところにある公開鍵、秘密鍵をそれぞれ切り出せばOKです。

vpnux clientでは、

こんな感じで設定します。

C#でJSONを出力する

C#でJSONを出力する必要に迫られたのでメモ。

まずは、出力するJSONを定義します。
サンプルとしてはこんなのを作ります。

まずは、JSONをC#のクラスに変換します。
VSでもできるようですが、json2csharpをつかいます。


作成されたクラスを少々手直しして、クラスとして追加します。

これをつかってJSONを作成します。
ここでは、Json.NETをつかいます。
こんな感じで組み立てていきます。


完成したサンプルコードはここに置いておきます。

Windows 10で、Chromeがおかしくなった。

Windows 10 にして、Chromeの挙動がおかしい時が多々ありましたが、
今回Creators Updateを当てたところ、機能拡張を入れるとフリーズ。リンクやボタンにマウスカーソルを持って行ってもクリックできない。プルダウンメニューが選択できない。ページが表示されない。など動作に支障が出るレベルになり、
キャッシュクリア、プロファイルの削除、Chrome再インストールなど試したがどれも効果なく。
怒りでFFに乗り換えるか。とも思いましたが、ググるとどうもグラフィックドライバ回りが怪しいとの情報が。
そういえばこのPC、インテルが正式にはグラボドライバ出していなく、MS製の割と不安定な奴が入っていました。
試しにIntelのドライバ更新プログラム走らせるも、該当ドライバは出てくるがインストール時不明なエラーでインストールできずOrz
うーんと設定眺めていると怪しそうなものを発見！！

なんとこれで直りました！！

SourceTree 2.0で過去開いたリポジトリが出ない

SourceTree2.0系が出ましたね。
画面や操作性が結構変わっていて戸惑います（汗

そんな中で、1.9系にあった、過去開いたリポジトリの選択画面がない！！
となったので、ちょっとしたTipsです。
（ちなみに、インストール時にちゃんと出ていることを後で確認しました・・・）



なんか空のタブが開きそうなUIですが、これをクリックしますと・・・


こんな感じで出てきます。

Let's Encryptで証明書を取得する

ググればいくらでも出てくるのですが、防備のために。

Ubuntu 16.04で試しました。

まず、取得のためには、Webサーバが外部に公開されている必要があります。
つまり、Port443(or 80)で外部よりサーバへアクセスできる必要があります。
また、当然ですが名前解決できる必要があります。
しかし、DDNSだと、週に取得できる上限が20個までという制限に引っ掛かる為、
一部のDDNSを除いて、取得しようとすると以下のようなエラーになります。

An unexpected error occurred:
There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for: dip.jp
Please see the logfiles in /var/log/letsencrypt for more details.

 なので、気長に待ちましょう。一日に何回もたたいても取得できないものは取得できません。

自分は取得できるまではオレオレ証明書で過ごしました。Cronで１日一回取得コマンドを叩いてチェックする感じ。一か月くらいかかったかな？

では、新規取得について。cerbotという自動取得プログラムをセットアップします。

cd /usr/local
git clone https://github.com/certbot/certbot
cd certbot
./certbot-auto -n

これで、インストールが完了しました。

必要に応じパスを通すなどしてください。

次に、証明書を取得します。自分は既にオレオレ証明書で外部にWebサーバを公開していたので、

そこを利用する設定にしました。

/usr/local/certbot/certbot-auto certonly --webroot \
-w /var/www/html -d xxxx.dip.jp \
-m admin@example.com --agree-tos -n --dry-run

-mで指定する連絡先メールアドレスは、証明書の更新期限が近づいてくると連絡が来るそうなので、管理用メアドをセットします。

まずは--dry-runにて動作を確認後、OKなら外して動かします。

デフォルトではPort443で通信するようです。

気長に待つと、そのうち下記のようなメッセージが出て、取得できます。

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for xxxx.dip.jp
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0020_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0020_csr-certbot.pem
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/xxxx.dip.jp/fullchain.pem. Your cert will
expire on 2017-0X-XX. To obtain a new or tweaked version of this
certificate in the future, simply run certbot-auto again. To
non-interactively renew *all* of your certificates, run
"certbot-auto renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

早速取得できた証明書をApache、PostFix、Dovecotにセットします。

Apache:
SSLCertificateFile /etc/letsencrypt/live/xxxx.dip.jp/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/xxxx.dip.jp/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/xxxx.dip.jp/chain.pem

PostFix:
smtpd_tls_cert_file = /etc/letsencrypt/live/xxxx.dip.jp/cert.pem
smtpd_tls_key_file = /etc/letsencrypt/live/xxxx.dip.jp/privkey.pem
smtpd_tls_CAfile = /etc/letsencrypt/live/xxxx.dip.jp/chain.pem

Dovecot:
ssl_cert = </etc/letsencrypt/live/xxxx.dip.jp/fullchain.pem
ssl_key = </etc/letsencrypt/live/xxxx.dip.jp/privkey.pem

このパスは当然ながら最新の証明書へのシンボリックリンクとなっており、
証明書が更新されてもパス、ファイル名が変わらないようになっています。

無事セット出来たら、次は更新処理を行います。
以下のスクリプトを作成し、cron.dailyあたりに放り込んでおきます。
(なお、取得は制限がありましたが、更新は制限がないようです。）

#!/bin/bash
/usr/local/certbot/certbot-auto renew --no-self-upgrade --post-hook "service dovecot restart && service postfix restart && service apache2 restart" --dry-run

ここでは、--post-hookを利用して、証明書が無事取得できたら、Apache、PostFix、Dovecotを再起動するようにしています。
これも、ちゃんと動作するかdry-runでテストを行いますが、
dry-runでも--post-hookは発動してサービスが再起動しますので注意です。
証明書の取得更新作業は今まで大変面倒で、しかも決して安くはないうえに、来るのは数十キロバイトの文字列だし、なんで自動化できないのか。これは一部独占企業による既得権益なのか？（こら
と思っていましたがやっと自動化になりましたね。
Amazonも自動証明書発行やったり、インフラがコードでどんどん自動化、使い捨てが進んでいく流れで、自動化を推進するのは大変良いことです。

Thunderbirdで何故か違う送信者で送信される

Thunderbirdで複数アカウントを登録している場合、
正しいアカウントでメールを送信したにもかかわらず、登録されている違うアカウント名義で送られることがあります。

これ、質が悪いのが、ちゃんと正しいアカウントの送信トレイに残り、しかもそこのFromのアドレスは正しいのですが、実際送られたメールのFromは違うアカウントになっています。

で、原因はこれです。




複数アカウント毎に通常それぞれSMTPサーバが設定されているのですが、
何かの拍子に既定のSMTPサーバになることがあります（汗

でどうなるかというと、このアカウントの受信は問題ないのですが、送信時はこの規定のSMTPサーバから送られます。
この時アカウントを記憶させておくと、しれっとFROM書き換わって送られます（汗

ThunderbirdはSMTPサーバの設定がここともう一か所あります。



ここが正しいからと言って、各アカウントのSMTPサーバ設定の選択とペアで合わせないとこういうことになります。
ちなみに、何故か各アカウントのサーバ設定項目ではなく、アカウント名をクリックしたところにあるので非常に見つけにくいです。

気を付けましょう。

Ubuntu 16.04でシェルを動かすと、変数展開に失敗し、 Bad substitutionとでる。

CentOSでは問題なく動いていたスクリプトが、Ubuntu16.04に持っていくと、
変数展開する箇所で Bad substitutionと出て動かなくなりました。

これ、地味に悩んだのですが、結果はあっけなく

#!/bin/sh

を

#!/bin/bash

に変えるだけでした。

どうも変数展開自体がbashの機能らしく、CentOSではshでもbashが動くようですが、Ubuntuは古い動作をするようです。

CentOSなどRedHat系になれていると、UbuntuなどDebian系はいろいろ勝手が違います・・

Ubuntu 16.04でcron.daily、cron.hourlyが動かない

Ubuntu 16.04でcron.dailyやcron.hourlyに入れたスクリプトが起動しないことがあります。

でも、実行権限などは付与しており、手動では動きます。

これ、どうやらUbuntuのcronの制限で、ファイル名にドットがあるとダメのようです。

なので、

root@hogehoge:/etc/cron.hourly# ls -lah
合計 16K
drwxr-xr-x   2 root root 4.0K  4月  5 00:41 .
drwxr-xr-x 103 root root 4.0K  4月  5 00:00 ..
-rw-r--r--   1 root root  102  4月  6  2016 .placeholder
-rwxr-xr-x   1 root root  402  4月  5 00:37 log-check.sh  <--これはダメ

拡張子を省きましょう。

Dovecot+自己証明書でtlsv1 alert unknown ca:SSL alert number 48がでてつながらない

Dovecot＋SSLで自己証明書を使った場合、ログインできません。

（Ubuntu 16.04+Dovecot 2.2.22で確認）

エラーログには

tlsv1 alert unknown ca:SSL alert number 48

という風に出て、中間証明書が読めていないような感じになります。

ここなんかだと、中間証明書をdovecotの設定ファイルに指定しろとありますが、

問題は解決しません。

これ、正解は自己証明書を生成したときに使った中間証明書をメーラーの信頼する認証局に登録する。です。

これ、結構見つからなかったのでメモしておきます。

裸族のテラハウスを買ってみた

そろそろ自宅サーバのディスク周りを改善すべく、RAID1を組める手ごろな箱を探していたところ、裸族のテラハウスを買ってみました。

早速検証してみたのですが・・・

• 何故かRAIDがリビルドされない
• リビルドされないときはディスクを抜いて、リセットボタン（と書いてあるけど説明書にはモード切替ボタンとある）を押しながら電源入れて初期化しろとある
• この段階でかなり怪しい・・・
• 取説通り生きたディスクを外し、スタンダードモードで交換後のディスクのみ刺して単品ディスク認識させ、フォーマット後、RAID1モードでディスクを戻したら、
  なんとびっくり空のディスクと同期されてデータ消失（ぉぉぉ
• どうも下のディスク（たぶん０番）と同期されるみたい
• 何かの拍子にディスク一つしか刺していないのにゴーストが見える（汗

とても怖くて使い物にならないし、これは初期不良じゃないか？と思うのですが、

どうも挙動から推測するに、RAIDモードの切り替え認識がうまくいっていない感じでした。

なので素性を調べたところ、公式がバラしてました（汗
どうもJMICRONのチップを使っているようです。
さらに画像検索とチップなどで調べたところ、本家を発見（汗

ここのOEMで間違いないようです。

（あれ？本家ではHotSWAP出来るげなことが書いてあるけど・・）

さて、中身はどうやら単純にJMS562を使ったRAIDのようです。
ということは、何かしらの管理ソフトを使えば制御できそうです。

ということで、JMICRONを使ったRAID管理ソフト・・・このあたりが使えそうです。
管理ソフトを入れてみたところ、案の定RAID情報がうまく読めていないようでした。

なので、ソフトから一旦RAIDを削除ー＞作成したうえで、初期化したディスクを突っ込むと無事リビルドが走りました。
以前RAID構成で使ったディスクは設定が残っているようで、刺してもリビルドしないので、いったんソフトから該当ディスクをRAID削除（！）するとOKのようです。
（一応ダメもとでHotSWAPしてみたけど大丈夫ぽい？？）

さて、速度を測ってみました。
サーバなのでUSB3.0ではなく安定のeSATAでつなぎました。

内蔵ディスクより早い結果に・・・

Ubuntu 16.04でClamsmtpdが起動しない

地味にはまったのでメモ。

Ubuntu16.04でClamSMTPを動かすと、/var/run/clamsmtpd/に書き込みができないとエラーになり起動しないことがあります。

これ、たとえchown -R clanav. /var/run/clamsmtpdしても、再起動したらダメです。

何故かというと、Ubuntuの/var/run配下はtempfsというファイルシステムでマウントされていて、これはメモリ上にあるので、再起動すると消えるんですね。

で、対処法ですが、systemdで起動しているスクリプトを修正します。

vi /etc/init.d/clamsmtp

 58 d_start() {
 59         if [ ! -d $RUNDIR ]; then
 60                 mkdir -p $RUNDIR
 61                 chown clamav:clamav $RUNDIR  #ここをclamsmtpからclamavに変える
 62         fi

しかし、CentでもUbuntuでもClamavのコロコロユーザ変えるのは毎度トラブルの元ですね。何とかしてほしいものです。

メモ：Simple:LDAPをコンパイルするのに必要なもの

毎度苦労させられるのでメモ。

CPANがちゃんと依存関係解消してくれればこんな苦労しなくて済むのだが・・・

yum install mod_perl perl-Crypt-PasswordMD5 perl-Params-Validate perl-Digest-SHA1 perl-DBI perl-DBD-MySQL56 perl-LDAP gcc gcc-c++ make zlib-devel curl-devel openssl-devel apr-devel apr-util-devel mod_perl-devel
yum install perl-CPAN
yum -y install libyaml-devel
yum -y install *YAML*
perl -MCPAN -e shell

CPANサイトがダウンしていることがあるので、ミラーを日本に設定
cpan>o conf urllist pop http://mirrors.vinahost.vn/CPAN/
cpan>o conf urllist push ftp://ftp.jaist.ac.jp/pub/CPAN/
cpan>o conf urllist push http://ftp.riken.jp/lang/CPAN/
cpan>o conf urllist push http://ftp.kddilabs.jp/CPAN
cpan>o conf commit
cpan>install YAML
cpan>install Attribute::Handlers
cpan>install Authen::Simple::Adapter
cpan>install Authen::Simple::LDAP

自作電源装置をバージョンアップ

中学の頃に自作して地味に今も生き残っている電源装置をバージョンアップしてみました。

今回、多回転ボリュームをAitendoで安く入手できたので、今まで使っていたボリュームと交換です。

精度は微妙ですが、今までは慎重にボリュームを回さないといけなかったので少し使い勝手がよくなりました。
取り外したボリュームの抵抗が時代を感じますね。

Aitendoの安い多回転ボリュームをばらしてみた

昔は（今もか？）高級品でとても手が出なかった多回転ボリューム（ポテンショメータともいうかな。）ですが、Aitendoで安く入手できたので、興味本位でバラしてみました。

ねじを外して分解したところ。

なんと既にネジの一つが馬鹿になってました（汗

構造的には巻き線抵抗器ですね。

摺動部はこんなかんじ。

巻き線抵抗部分にそって、先端の接点がなぞる原理です。

裏側はこんな感じ。

摺動部での電気は先端の摺動部で本体端子に伝えられます。

ってこれ抵抗精度悪そうだな。

滑りも途中若干引っかかるし。

DVDドライブをちゃんと修理してみた。

以前修理したジャンクDVDドライブですが、このたび、Aitendoでフレキケーブル(FFC）を入手できたので、ちゃんと修理してみました。

このDVDドライブで使用されているフレキケーブルは、57Pinで0.5mmピッチのもので17Cmくらいの長さです。
で、こんな変則的なケーブル、流石のDigiKeyやRSコンポーネンツなど主要な販売サイトではなく、あの天下のAmazonにもない。で唯一Aitendoにある（笑）
流石中華パワーである。
この種類の豊富さはすごい・・・

で、届いたものは長さが長いのですが、前回みたいにカット＆ヤスリ掛けで端子整形なんていう職人芸はやりたくないので、取り回しに少々苦労しながらもなんとか実装。



ついでに、電源がどうもヘタっているようなので、手持ちにあるコンデンサを適当に実装。
モータ始動時の安定性が気持ち向上した・・・気がする。

電卓を修理するために電卓を買ってきた

長年使っている電卓のキーパッドがヘタって来たので、昔ながらの鉛筆で延命措置を図ったのですが、修理するつもりが壊してしまい（汗・・・
広島で電卓用太陽電池なんて入手出来る訳もなく、仕方がないので100均で電卓を買ってきてもぎ取りました。



長年使っている電卓。物自体はかなり古いものです。
よく使う電源SW兼ACキーが利きが悪くなっています。



サクッと分解します。
作りが時代を感じますね。
基板自体はプラスティックの頭を溶かして潰すことで止めてあります。
で、この頭をカッターでカットすればいいのですが・・・・・・・
昔のものなので無駄に丈夫で、なかなか切れない。
そうこうしているうちに、カッターを滑らせてしまい・・



はい。やってしまいました。
今は亡き貴重なSANYO製太陽電池を壊してしまいました（涙）



ほかにも基板のレジストを剥がしてしまいました。
幸い断線はしていませんが、最近仕事が忙しく寝不足なのもあって焦りと注意力散漫が出た結果ですね。



こいつは（当時画期的だった）TwinPowerなので、太陽電池がなくても内蔵電池で動くのですが、どうにか修理したい・・・
（指が痛い＞＜）



で、部品取りになりそうなものを100均で入手。
太陽電池が実はダミーでした。（昔の100均電卓はそんなのがあった）を考慮し、太陽電池で動くおもちゃも購入。



電卓を分解。なんと構造がほぼ同じ（笑）
太陽電池も生きています。うーん。時代の流れはすごい。
電池と太陽電池ついた電卓が100円ですか。
この電卓、当時いくらしたんだろう・・・
（修理せずこれ使えばいいんでは？というのはナシで）



手ごろな配線がなかったので、100均電卓から配線をもぎ取る。
太陽電池のサイズが2回りほど小さく、穴ギリギリの大きさだったので、万能工具、ホットボンドで丁度いい位置に固定。
あとスポンジゴムをいい具合に張り付ける。



どうでしょう。
若干太陽電池のところに隙間がありますが、見た目と機能はなんとか回復できたかな。

げげっ・・・

朝ノパソつけたらこんな状況Orz

原因はカバンの中に一緒に入れていた弁当から汁が漏れていたのと、蓋の締まりが悪かったペットボトルからの漏水によるダブルコンボ。

まぁ原因がわかれば修理の目途は立つわけでして・・・

バラして浸水した個所をクリーニング。今回は液晶への接続コネクタ部を特に入念にクリーニング後組み立てて修理完了！

まったく・・・手間かけさせやがって。

１００均の新しいバージョンを入手

100均で某社製アダプタにそっくりな物を入手しました。

初代は分解済みなので、次世代機（？）はどうなっているのか・・・

一応初代同様PSEマークはあります。

一応２４０V入力だそうです。

試しに手持ちのiPhoneを繋いでみました。

お？公称通り約１Aでました。しかも電圧降下もないようです。（むしろ若干高い？）

この時点で中身は初代と違うっぽいですね。

比較のために初代を持ち出しました。こんなもんです。

ではお決まりの（？）分解です～

初代に比べ格段に開けやすくなっていますね。

たまたま接着が甘いのかもしれませんが、マイナスドライバーでカパッと空きました。

初代みたくリューターでガリガリ削らなくてもいいです。

ACは初代と違い接触式に変更されています。省力化なのでしょうか？

少なくとも接触不良による放電が怖いです・・

絶縁テープを外して取り出してみました。

初代にはそんな物は無かったので安全に配慮したのかもしれません。

見ての通り、二次側からのフィードバックはないようです。

初代は一応あったのですが、コストの兼ね合いなのかもしれません。

あと、初代にはなかったサージ対策？のコンデンサがついています。

また、初代はスイッチング用TRとしてパワトラがついていましたが、今回は普通のTO-92にみえます。

裏面です。

初代と比較し、ブリッジダイオードが表面実装になっています。

また、スイッチングが初代の自励式（？）ではなく、IC(おそらくPWMコントローラ？）制御になっています。

ICの型番はググってみたけどわかりませんでした。

部品点数は初代と比べ若干多くなったかな？（CR類の数が増えている感じ）

回路図を起こしてはみたのですが清書する時間がない・・