:::: MENU ::::

Error: uninitialized constant Formulary::HOMEBREW_CORE_FORMULA_REGEX

MacのHomebrewでアップデートをかけると、またもや下記のエラー

Error: uninitialized constant Formulary::HOMEBREW_CORE_FORMULA_REGEX

$ brew update
Error: uninitialized constant Formulary::HOMEBREW_CORE_FORMULA_REGEX
Please report this bug:
    https://git.io/brew-troubleshooting
/usr/local/Library/Homebrew/formulary.rb:227:in `loader_for'
/usr/local/Library/Homebrew/formulary.rb:176:in `factory'
/usr/local/Library/Homebrew/cmd/update.rb:173:in `block in report'
/usr/local/Library/Homebrew/cmd/update.rb:159:in `each_line'
/usr/local/Library/Homebrew/cmd/update.rb:159:in `report'
/usr/local/Library/Homebrew/cmd/update.rb:24:in `update'
/usr/local/Library/brew.rb:140:in `<main>'

gitのトラブルシューティングを見ろとの事で、https://github.com/Homebrew/homebrew/issues/42553に書いてありました。

もう一度、brew updateをかければ良いみたいです。

$ brew --version
0.9.5
$ brew update
Already up-to-date.

Debian 8(Jessie)にVMware Toolsをインストール

前記で、Debian 8(Jessie)をVMware Fusion上にインストールしたので、VMware-Toolsを導入しました。

まずは、VMwareTools導入にあたり、必須となるファイルやプログラムをDebian上にインストールします。

# apt-get install gcc make perl
# apt-get install linux-headers-$(uname -r)

MacのVMware Fusion上のメニュー欄から仮想マシンのVMware Toolsのインストール選びます。
すると、/media/cdromへマウントされます。

その中の既存のインストーラを起動しようとすると・・下記のエラー

chmod: `./vmware-tools-upgrader-64′ のパーミッションを変更しています: 読み込み専用ファイルシステムです

なので、/tmp/に展開してインストール

# tar zxf /media/cdrom/VMwareTools-9.9.2-2496486.tar.gz -C /tmp
# cd tmp/mware-tools-distrib/
# ./vmware-install.pl

再起動後、VMwareToolsが有効になっている事と思います。


Debian wheezy(7.8) から jessie(8.0)へアップグレード

Debianが約2年ぶりにメジャーアップグレードで、Debian 8.0 Jessieがリリースされましたので、早速、既存の7.x(wheezy)からアップグレードを行ってみました。
メジャーアップグレードでリリースされたばかりなので、用心をとって、VMware Fusion上にてテスト的にアップグレードです。

VMware Fusion上で、7.8(wheezy)をnet installした後、8.0(jessie)へのアップグレード方法です。

もし、運用しているwheezyをそのままアップグレードする場合には、/etc下やapt関連のバックアップを取ってから行った方が良いでしょう。

  1. 既存のパッケージを更新しておきます。
    # apt-get update; apt-get upgrade
    また、整合性の競合がないことも確認しておきましょう
  2. wheezyからjessieへsourcelessを変更
    # sed -i 's/wheezy/jessie/g' /etc/apt/sources.list
  3. 更新・アップグレード
    # apt-get update
    # apt-get upgrade
    # apt-get dis-upgrade
  4. 掃除
    # aptitude purge '~c’
  5. 再起動
    # init 6
  6. バージョン確認
    #lsb_release -aNo LSB modules are available.
    Distributor ID: Debian
    Description: Debian GNU/Linux 8.0 (jessie)
    Release: 8.0
    Codename: jessie

以上で、7.xから8へのアップグレード完了です。

jessieから、GNOMEが標準になったり、標準のinitシステムがSysVinitからSystemdへ変更されたりと、7.xとは大幅な変更がありますし、リリースされたばかりと言うこともあり、不具合も出る可能性が大いにあるので、急がなければ、1ヶ月近くは様子をみて、アップグレードした方が良いかと思われます。


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%にも減りましたとさ。


ページ:1234567...25