:::: MENU ::::

Scientifix Linux 6.4から6.6へアップグレード

ここのサーバで稼働しているScientific Linux 6 (sl6)を、バージョン6.4で止まったままでしたので、最新(現時点で6.6)へアップグレードしました。

一応、バージョン確認

$cat /etc/redhat-release
Scientific Linux release 6.4 (Carbon)

普通にyum updateしても、最新へアップグレードされないままでしたので、下記コマンドで無事6.6へアップグレード。

# yum install -y yum-conf-sl6x
yum clean all
yum update

アップグレード後、再起動して確認
$ cat /etc/redhat-release
Scientific Linux release 6.6 (Carbon)


Macでjavaのjarファイルを実行

時々、Mac上のターミナルで、Javaのjarファイルを実行したい時があるのでメモ。

javaの起動には、Java Developer Kitが必須のようなので、下記のアドレスからMac版をダウンロードして、インストールしておく。


http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
ちなみに現時点だとjdk-8u40-macosx-x64.dmg

その後に、下記コマンドで実行

$ java -jar jarfile.jar

複製したVMwareゲストOSがネットワークにつながらない時に確認するポイント

VMware Fusionで他からコピーしてきたCentOSのゲストOSをそのまま起動しようとすると、デバイス名(eth*)が認識されなくてネットワークが利用できません。ちなみにVirtualBoxでも同様だと思います。

# ifconfig -a

loしか表示されず、eth*が表示されない

ここでのポイントは、MACアドレスとデバイス名を確認し、修正する事で、おおよそ解決できるかと思います。

MACアドレスの確認と修正

確認

ゲストOSのCentOSを起動後、ログインし、/etc/sysconfig/network-scripts/ifcfg-eth0(←この数字は環境に合わせて)を確認します。

# cat /etc/sysconfig/network-scripts/ifcfg-eth0
ここで表示されたHWADDRのMACアドレスを確認します

次に、VMware Fusion上の起動したCentOSの設定より、ネットワークアダプターを選び、下部の詳細オプションをクリックします。

表示されたMACアドレスが新しいものなので、ifcfg-eth0内のMACアドレスをこれに置き換えます。

保存後に、ネットワークを有効化します。

# /sbin/service network start

この後に、何もエラーが出ずに、ネットワークが利用できるのであれば、これだけで終了です。

しかし、ほとんどが、下記のエラーが出る場合が多いです。

Device eth0 does not seem to be present, delaying initialization

デバイス名の設定変更

# cat /etc/udev/rules.d/70-persistent-net.rules

# PCI device 0x8086:0x100f (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:92:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x100f (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:65:yy:yy", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

同じネットワークデバイス名が存在し、上記が古いMACアドレス、下記が新しいMACアドレスになっているかと思います。
下記のMACアドレスが、上図の詳細オプションで表示されたMACアドレスになっていることを確認し、上記の古い情報(デバイス、MACアドレス)を削除します。

このままでも問題はありませんが、ネットワークデバイス名がeth0でなく、eth1となってしまうので、eth1をeth0に変更すると良いでしょう。

この後、OS再起動するとネットワークが利用できる環境になっている事と思います。


コマンドラインで Macのバージョン確認

普通にMacを目の前にして、GUIにてMacのバージョンを確認するには、アップルメニューから「このMacについて」を選択するだけですけど、SSHで遠隔ログインしている時に、あれ?バージョン確認ってどうやるんだろうと思ったのでメモ。

ターミナルから、sw_versと打つだけ。

$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.9.5
BuildVersion: 13F34

/System/Library/CoreServices/SystemVersion.plistを読んで表示しているよう。


Mac OS X でネットワークの優先順

iMacを使ってて、素朴な疑問!

UTPケーブルで有線接続して、WiFiで無線接続している場合、時にはVPN接続する場合、ネット接続ではどちらが優先されるんだろう?とふと考えてしまいました。

答えは、アップルの公式ページに書いてありました。
http://support.apple.com/kb/PH7119?viewlocale=ja_JP&locale=ja_JP

  1. アップルメニュー>「システム環境設定」と選択し、「ネットワーク」をクリックします。
  2. 「アクション」ポップアップメニュー(歯車のアイコン)から「サービスの順序を設定」を選択します。
  3. 「Ethernet」などのサービスをリストの一番上にドラッグします。
  4. 「OK」をクリックしてから「適用」をクリックして、新しい設定を有効にします。

リスト上位から優先され、VPN接続する場合は、上位に持っていく必要がないとの事で、疑問が解決してスッキリです。


Linux上で重複したファイルを探して削除する

Linux上で重複したファイルを削除するツールにfdupesというツールがあります。
findなどで、単にファイル名やファイルサイズを比較しても、中身が同じであるとは限りませんが、fdupesは、ファイルサイズとmd5ハッシュ値を比較して、重複ファイルを抽出するので、ほぼ間違いないツールだと思います。

fdupesは標準では入っていないので、インストールする必要があります。
Debian系だと、そのままapt-getでインストール

# apt-get -y install fdupes

RedHat系だとepelのリポジトリにてインストール出来ます。

# yum -y install fdupes --enablerepo=epel

使い方
あるディレクトリ内を再帰的に重複ファイルを検索

$ fdupes -r ~/Dropbox/

重複ファイルを対話形式で削除

$ fdupes -rd ~/Dropbox/

最初に検索されたファイルを除外し、確認しながら削除

$ fdupes -frdN ~/Dropbox/

最初に検索されたファイル以外を問答無用で削除

$ fdupes -fr ~/Dropbox/ | xargs rm

注意事項
-fの引数で最初に検索されたものが除外されるが、果たして、この除外されたファイルが実際に残しておかなくてはならないのか判断する必要があります。
中には重複したファイルが、あるディレクトリ内になくてはならないものも存在します。

ですので、一番安心な方法は、fdupes -rで検索した結果をリスト化して、自分の判断で削除する事ですね。

$ fdupes -rf ~/Dropbox/ | sort | uniq | grep -v '^$' > duplicate.txt

ルート領域がフルになりそうなのでコマンドラインで確認してみる

このサイトでは、Sientific Linux 6.xの64bitで運用しており、ハードディスク容量を見てみたところ、99%使用で、危うく100%超しそうでした。

WindowsやMacでは、GUIでグラフィカルなHDD容量チェックルーツがたくさんあります。もちろんLinuxでもないわけではありませんが、コマンドラインの方が簡単で慣れてるので、コマンドラインでチェックです。

全体の容量を見るには、df -Hでパーティション毎に、容量情報を見ることが出来ます。
調べてみたところ、ルート(/)領域が99%で、その中でも/usr以下がほぼ占めてた。

それで、/usr/以下を下記コマンドで調べてみた。

# du -s /usr/* | sort -n
1.5M ./bin
4.0K ./etc
4.0K ./games
4.0K ./lib64
4.0K ./libexec
4.0K ./sbin
4.0K ./src
36G ./vpnserver
87M ./lib
382M ./rbenv
436K ./share
688K ./include

vpnserver下が圧倒的に容量を喰っていたので、さらに調べていったら、ログが溜まっていたのが原因でした。
あっさりとログを削除したころ、HDD空き容量が99%から20%にも減りましたとさ。


cpコマンドで複数のファイルを一括でシムリンク

Linux/Macなどでシンボリックシンク(シムリンク)を張る際に、通常だと”ln -s file1 files2″みたいに行います。
しかし、複数のシムリンクを作成する際に、lnではワイルドカードが使えないので、一つ一つでの作業となり面倒です。

達人になると、findとxargもしくはforループなどのインラインコマンドやシェルスクリプト,perl,rubyで簡単なプログラムを書くのでしょうけど、もっと簡単な方法はないのだろうかと思っていました。

(CentOS6.xのLinuxの場合で説明)
たとえば、Muninのプラグインファイルをシムリンク張る際に、
大元のファイルは、/usr/share/munin/plugis/に入っており、この中から有効にしたいファイルを/etc/munin/plugins/へシムリンクを作成します。
今回は、postgress関連のシムリンクを張ってみます。

まず、postgress関連のファイルを確認すると、

$ ls /usr/share/munin/plugins/postgres_*
/usr/share/munin/plugins/postgres_autovacuum
/usr/share/munin/plugins/postgres_bgwriter
/usr/share/munin/plugins/postgres_cache_
/usr/share/munin/plugins/postgres_checkpoints
/usr/share/munin/plugins/postgres_connections_
/usr/share/munin/plugins/postgres_connections_db
/usr/share/munin/plugins/postgres_locks_
/usr/share/munin/plugins/postgres_oldest_prepared_xact_
/usr/share/munin/plugins/postgres_prepared_xacts_
/usr/share/munin/plugins/postgres_querylength_
/usr/share/munin/plugins/postgres_scans_
/usr/share/munin/plugins/postgres_size_
/usr/share/munin/plugins/postgres_streaming_
/usr/share/munin/plugins/postgres_transactions_
/usr/share/munin/plugins/postgres_tuples_
/usr/share/munin/plugins/postgres_users
/usr/share/munin/plugins/postgres_xlog

これらのファイル全部を一つ一つlnコマンドでシムリンク張るのは、かなり面倒ですよね。

そこで、Linux/Unixを触ったことがある方なら誰でもご存じのcpを使います。
そう、ファイルをコピーするコマンドのcpです。

では、早速作業してみましょう。

# cd /etc/munin/plugins/
# cp -s /usr/share/munin/plugins/postgres* .

 cpコマンドに-sの引数をつけてやるだけで、あら不思議、簡単にシムリンクが張れます。

尚、シムリンク作成出来るcpは、FreeBSDやSoralisなど違うプラットフォームまたはバージョンによっては、使えないかもしれませんので、バージョンを確認し、man cpで-sが使えるか確認しましょう。

$ cp –version
cp (GNU coreutils) 8.4

作業後に、シムリンクが張れているか確認してみると、まとめてシムリンクが張られ作成されることが確認できました↓

postgres_autovacuum -> /usr/share/munin/plugins/postgres_autovacuum
postgres_bgwriter -> /usr/share/munin/plugins/postgres_bgwriter
postgres_cache_ -> /usr/share/munin/plugins/postgres_cache_
postgres_checkpoints -> /usr/share/munin/plugins/postgres_checkpoints
postgres_connections_ -> /usr/share/munin/plugins/postgres_connections_
postgres_connections_db -> /usr/share/munin/plugins/postgres_connections_db
postgres_locks_ -> /usr/share/munin/plugins/postgres_locks_
postgres_oldest_prepared_xact_ -> /usr/share/munin/plugins/postgres_oldest_prepared_xact_
postgres_prepared_xacts_ -> /usr/share/munin/plugins/postgres_prepared_xacts_
postgres_querylength_ -> /usr/share/munin/plugins/postgres_querylength_
postgres_scans_ -> /usr/share/munin/plugins/postgres_scans_
postgres_size_ -> /usr/share/munin/plugins/postgres_size_
postgres_streaming_ -> /usr/share/munin/plugins/postgres_streaming_
postgres_transactions_ -> /usr/share/munin/plugins/postgres_transactions_
postgres_tuples_ -> /usr/share/munin/plugins/postgres_tuples_
postgres_users -> /usr/share/munin/plugins/postgres_users
postgres_xlog -> /usr/share/munin/plugins/postgres_xlog

Linux/Unixを10年以上も触っているに、cpコマンドでシムリンクが作成できるのを初めて知りました。お恥ずかしい・・


MacのターミナルにてSolaris上のviでxtermエラーが出るときの対処

MacのターミナルやiTermにて、SunOS(Solaris)にログインし、viを起動すると、下記のエラーが出ることが多々あるのでメモ。

$ vi
xterm-256color: Unknown terminal type I don't know what kind of terminal you are on - all I have is 'xterm-256color'. [Using open mode]

Mac側ではxterm-256colorなのですが、Solaris側ではxterm-256colorって知らんよ!って事なので、Mac側の環境変数TERMを変更してあげればOKです。

Solaris10で使用可能なterminfoは、下記のようにして調べることが出来ます。

$ ls /usr/share/lib/terminfo/x
x1700 x1750 xitex xpcterm xtalk xtermc xterms
x1720 x820 xl83 xpcterms xterm xtermm

(ちなみに、Linuxでは/usr/share/terminfo/xです。)

これを元に、Mac側のターミナルで、環境変数を設定

$ vim ~/.bash_profile
$ export TERM=xterm
$ source ~/.bash_profile

Lazy galleryでサムネイルが表示されなくなった不具合

私が担当しているとあるブログで、サーバ:Coreserver、CMS:WordPressにて運用しており、アルバムのプラグインとして、lazy galleryと言うプラグインを利用しており、WordPress本体とプラグイン更新以外は手を付けておりませんでしたが、いつの間にか、閲覧が出来なくなってしまいました。

推測すると、たいていサムネイルが作成されていないか、パーミッションが適切でないことが多いですが、対処として、

  • キャッシュの削除
  • メモリ不足によりメモリを増やす
  • サムネイルの再構築
  • Coreserverなので、パーミッションの確認

などを確認してみましたが、どれも解決には至らず。

Lazy galleryで作成したアルバムページのソースを眺めていたところ、サムネイルのリンク近くに、何だか別のCSSクラスがあることを発見しました。

原因は、プラグインの競合だったようで、Hammyと言うプラグインを外したところ、無事改善した。


ページ:1234567...24