「Linux」カテゴリーアーカイブ

2020年12月
日 月 火 水 木 金 土
 12345
6789101112
13141516171819
20212223242526
2728293031  

最新の投稿(電子情報)

アーカイブ

カテゴリー

Error Establishing a Database Connection

2020年11月17日

びびった。

この WordPress で、特に何もしていないのに、「データベース接続の確立エラー」（Error Establishing a Database Connection）
が表示された。コレが出ると、データベースファイルが壊れたとかの場合が多くて、復旧に手間取る可能性が高い。

今回は、サーバに login して、MySQL の Restart だけで復帰した。

払い下げPCへのddを使ったディスクイメージコピー

2020年3月19日

総合情報処理センターのパソコンの入れ替えにより、払い下げとなったパソコンのセットアップ中。

1台をWindows10などの環境を整えて、あとは、USBブートのUbuntuを使って、HDDを全コピー。

最初、SATA のケーブルを、コピー元=SATA0 と、コピー先=SATA1 につないでコピーをしたら、同一バスを使うからかな!?やたらと時間がかかり、1台あたり 290分かかった。

$ time sudo dd if=/dev/sda of=/dev/sdb
289min...

2度目からは、コピー元=SATA0で、コピー先=SATA1を、コピー先=SATA3に変更して、ついでにコピー単位を256kB に変更して行う。

$ time sudo dd if=/dev/sda of=/dev/sdb bs=256k
78min...

バッファーサイズが効果的だったのか、SATA3 にしたのが良かったのか…はよく判らないけど、コピー時間を1/3に短縮できた。

でも、残りあと10台以上セットアップは続く。卒業式が始まる前に、1ローテーション回してから、式に向かう。まだまだあるし、もう1つUbuntuのUSBを準備し、2台並行作業を開始。

ネットワークセキュリティのためのTips

2020年1月29日

usacloud

2020年1月6日

さくらのクラウド上のサーバを、実験・演習用に使っているけど、未使用時に起動していると課金も増えるので、極力電源を落としたい。調べると、さくらのクラウドであれば usacloud という CLI により操作ができるみたい。

同じネタを「機構管理の Azure のサーバでも極力電源を落とせ」と言われているけど、利用者のいるWebサーバなので困難。

APIキーの取得

usacloud の説明を見ているけど、API キーの取得画面の出し方が変更になっているみたい。さくらのクラウドホームにて、APIキーを発行

usacloud のインストール

usacloud のドキュメントには、

curl -fsSL https://releases.usacloud.jp/usacloud/repos/install.sh | bash

と書かれていたけど、debian の apt の GPG エラーでインストールに失敗したので、usacloud_0.31.1-1_all.deb をダウンロードし、dpkg -i *.deb でインストール。

先の手順で作ったAPIキーを登録

[root]# usacloud config
Setting SakuraCloud API Token => 
	Enter token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Setting SakuraCloud API Secret => 
	Enter secret: xxx...xxx 
Setting SakuraCloud Zone => 
	Enter zone[is1a/is1b/tk1a/tk1v]: is1b
Setting Default Output Type => 
	Enter default-output-type[table/json/yaml/csv/tsv]: json
Written your settings to /root/.usacloud/default/config.json

サーバの操作コマンド

設定が終われば、サーバの起動や停止もコマンド一発

((( サーバの起動 )))
$ sudo usacloud server boot 名前
$ sudo usacloud server wait-for-boot 名前
((( シャットダウン )))
$ sudo usacloud server shutdown 名前
$ sudo usacloud server wait-for-down 名前
((( サーバ一覧 )))
$ sudo usacloud server list
$ sudo usacloud server list -q
11xxxxxxxxxx
$ sudo usacloud server list --output-type table
+--------------+---------+-----+--------+------------+--------------------+--------+----------------+
|      ID      |  Name   | CPU | Memory | Commitment |     IPAddress      | Status |      Host      |
+--------------+---------+-----+--------+------------+--------------------+--------+----------------+
| 11xxxxxxxxxx | nitfcei | 2   | 2048MB | standard   | xxx.xxx.xxx.xxx/24 | up     | sac-xxxx-xxxxx |
+--------------+---------+-----+--------+------------+--------------------+--------+----------------+
$

VMware PlayerでLinux

2019年12月11日

授業の中で unix 環境を体験してもらうために、vmware player を使う準備

VMware Workstation Playerのインストール

Ubuntu 18 Desktop 版の起動イメージ

起動した状態のイメージを作っておきたかったが、Freeの環境では無理っぽいな。インストール作業を授業時間内にやるか…

nfsのソフトマウント

2019年10月8日

自室の Linux サーバでは、自分が管理している Azure 上のサーバのデータバックアップを取っているが、ハードディスク容量が巨大な訳でもないので、iMac に接続された Drobo (複数ディスクの改良RAID?) に保存させている。

このネットワーク越しのバックアップでのディスクアクセスになるが、iMac を時々再起動させると、その間に icinga のディスクチェック処理が走った際に、アクセスできないために df プロセスが大量に残るトラブルが発生していた。リトライするため CPU 負荷も高い状態で、一番簡単なのは サーバの再起動。(iMacを再起動したら、その後にLinuxサーバを再起動….無駄や…)

最初は、check_disk 処理で余計なところを見させないために、特定マウント先を無視するオプションを加えていたが、df がマウント先をしつこくアクセスをリトライするのが原因。

よく考えたら、ネットワーク越しのマウントだから、ハードマウント(ディスクアクセスに失敗したら何度もリトライ)ではなく、ソフトマウント(複数回リトライしたら諦める)にする必要がある。

ということで、automount オプションに、”soft” オプションを加えて解決。

MySQLでトラブル対応

2019年7月13日

仕事で動かしているサーバが動いていないとの連絡が入り、システムが動いていない。

他の方との共同のネタなので、サーバーの更新は慎重に行っているけど、今回は MySQL が落ちているのが原因。サーバーの定期的な更新作業後あたりから動かなくなっているので、最近更新されたパッケージを確認し、MySQL が含まれていたのでパッケージを一つ前のバージョンに落とそうと対応を行った。

しかしダウングレードでパッケージの不整合が出る中、無理やりダウングレードをおこなって MySQL を起動させようとするが、”mysqld got signal 11 ; This could be because you hit a bug.” といったメッセージで起動しない。

四苦八苦するも原因がつかめず、以前の状態に戻そうとバックアップ時に作成しておいたパッケージのバージョン情報を確認すると、パッケージが更新されて動かなくなったのではなく、パッケージが消されていたことが判明。原因を誤解していた。

OSの更新作業の中で、MySQL のメジャー更新で使っていたバージョンが標準パッケージから外されたみたい。メジャー更新すればいいのだろうけど、運用不安もあるので、MySQL の本家で公開しているパッケージを入れて、無事復旧。

長期運用とはいえ、更新は慎重に作業せねば。

gcj (GNU Compiler for Java) の使い方

2019年2月21日

いつもは Java を使わないけど、久々に java のプログラムの動作実験と思い、サーバ機に gcj (GNU Compiler for Java)を入れて使おうとしたら、コンパイラ javac とバイトコードインタプリタ java のつもりでコマンドを探すけど、見つからない。

gcj を見つけて “gcj HelloWorld.java” ってやってみたけど動かない。あらためて確認したら、バイトコード生成もできるし、直接機械語も生成できるけど、色々とオプション指定がいるみたい。なるほど。

// HelloWorld.java
public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello World!");
  }
}

# 機械語を直接生成する場合
$ gcj -o HelloWorld --main=HelloWorld HelloWorld.java
$ ls
HelloWorld  HelloWorld.java
$ ./HelloWorld
Hello World!

# バイトコードを生成して動かす場合
$ gcj -C HelloWorld.java
$ ls
HelloWorld.class HelloWorld.java
$ gij HelloWorld
Hello World!

プロセス状態 I (Idle Kernel Thread)

2019年1月16日

自宅のサーバの状態を見ていたら、青:sleep 灰:total の間の差が大きい。

変なプロセス走っていないかと心配したら、ps ax の出力でのステータスがIとかI< となっている項目。日本語のマニュアルを見ても意味不明。

英語のマニュアルを見たら、”Idle Kernel Thread”らしい。

緊急連絡システムのOS更新など

2018年8月10日

緊急連絡システムのOSが、Ubuntu/trusty でそろそろ、サポート期間に近づいているので、OS の更新を行った。

Ubuntu 更新

更新自体は、do-release-upgrade コマンドで、xenial に更新が進む。

$ sudo do-release-upgrade

しかしながら、openssh-server が、更新でエラーがでて、かなり悩んだ。解ってみれば、単純なミスで、自作の /etc/init.d/script を書いてあったけど、その insserv ヘッダで、ssh をコピーしてヘッダ部の # Provides: sshd の行を書き換えてなかった。

このおかげで、insserv が、ssh はすでに登録されている…と勘違いしていた。

緊急連絡システムの文字コードUTF-8 に変更

Ubuntu の更新をかけたら、php5 が使えなくなったため、php7.0 に更新を行うが、これに合わせ、取り扱い文字コードを EUC-JP から UTF-8 に変更を行った。

緊急連絡システムは、内部でデータベースを利用せず、テキストファイルですべてを管理しているが、最初は利用組織毎の設定ファイルや、データファイルをエディタでチマチマと修正を始めたけど、大量の組織のため、途中で断念。perl でファイル名や記載時のエンコーディングを修正するスクリプトを書いて一発変換。

あとは、プログラム中のエンコーディング依存の部分を修正し、送信できることを確認してひとまず移行作業完了。

投稿ナビゲーション

← 過去の投稿

検索・リンク

Google Office 365

システム

リンク集