うつ病けんけんのFedora/Linux日記 : サーバー管理

サーバー管理

2015年12月05日09:09

Fedora23上のVMWare Playerが無言で終了する！を解決する方法

カテゴリ: 仮想化; サーバー管理

Fedora23にアップグレードしてからVMWareが起動しなくなりました。
しかも無言で何もエラーメッセージを吐きません。

困ったなーと調べてたらFedora Forumuを見つけましてそこで修正方法を載せてくださっている
サイトがありましたので
リンクだけお知らせ。

リンク先の手順に沿って実行していくだけですから。

VMWare Worksation 12 on Fedora Core 23 (fc23）－－　Coyote's Blog

そしてこの設定にするとビンゴ！！
中々苦労しました^^;

タグ：: VMWarePlayer; 仮想化

2015年05月29日13:42

fedupを使ってFedora22（F22)へアップグレード。

カテゴリ: サーバー管理

Fedora22がリリースされました。
さらっとfedupを使ってアップグレード方法をば。

fedupでアップグレード

sudo fedup --network 22

放置しておくとrebootせよと言われるので再起動。

再起動後

アップグレード中のSS

F22

アップグレード後。ちゃんとFedora22になってます。

nautilusファイルマネージャーが落ちる

Nautilusを起動するとすっこんすっこん落ちました。
/homeですら。

なのでrm .config/nautliusをして設定ファイルを初期化。

これで落ちなくなります。
ただし、私の環境だと落ちるディレクトリがあったりして。
リネーム（ファイル名を変更）すると直るのですが…

タグ：: アップグレード

2014年09月26日14:11

[緊急]bashが危ない！！アップデートも良いけどシェルを変えておこう。

カテゴリ: サーバー管理

昨日の2014年09月25日（木）
「bash」シェルに重大な脆弱性、主要Linuxでパッチが公開 - ITmedia
が発表されてLinux界隈は大騒ぎです。

Fedora20では2014年09月26日（金）時点でもうすでに
sudo yum update bash
により
bash --version
GNU bash, バージョン 4.2.47(1)-release (x86_64-redhat-linux-gnu)
が出ています。

rpm -q --changelog bash | head
とコマンドを打つと

* 水 9月 24 2014 Ondrej Oprala - Inhibit code injection - patch by Stephane Chazelas

と出ており修正は入ってる模様。
（24日なのは時差だと思われる。

ですが、bashシェルの修正パッチは不完全、脆弱性突く攻撃の報告も　- ITmedia

とまだ脆弱性があるみたいです。

放っておけばアップデートが来ると思いますが
サーバーとして使っている場合は話が別です。

bashのパッチを当てて自分でビルドするってのもありなんですが、
少々面倒だしこれから来るパッチを当てても直ってないってこともあり得ると思います。

なのでtcshをインストールしてログインシェルとしておくという手がありますので
紹介したいと思います。

ちなみに業務スクリプトをbashで作っている場合はtcshに変えると動かないと思いますので
そういう方はパッチあててくださいな。

ちなみにzshを使ってるから大丈夫だぉって方も要注意です。
zshはbashからの拡張シェルですので。

tcsh

tcshインストール

まずはtcshをインストールします。



sudo yum install tcsh

ログインシェルを変える

次にログインシェルをtcshに変えます。
コマンドは以下を実行。



 chsh -s /bin/tcsh

とすれば



 hogehoeのシェルを変更します。

と返ってくるはずです。

rootのシェルを変えるには



sudo chsh -s /bin/tcsh root

で良いと思うのですがrootのシェルを変えてFedoraが起動しなくなるのでは…
と心配なので私の方では試していません。
rootのシェルこそ変える必要があるのですが。
sudoでしかroot権限を使わないから大丈夫なのかな？
よくわかりません。

仮想化上でシステムを作ってから動作チェックしてみてください。

ログインシェルの確認

シェルを変えたら一度ログアウトしましょう。
GNOMEを使っていたらGNOMEからのログアウトを、
端末だけなら使っている端末全てログアウトしてから
ログインし直しましょう。



echo $SHELL

と打ったら



/bin/tcsh

と表示されたらtcshに変わってる証拠です。

これでとりあえずは安心だと思うのですが、
まだまだコード修正が来ると思うので情報を追いかけておいてください。

ちなみにbashに戻したければ、



 chsh -s /bin/bash

と打ちます。

さて、それでは今日のところはこの辺で。
久々に記事書いたな…

タグ：: アップデート

2014年08月27日14:12

rsyslogがCPUリソースを食いまくる問題を解決する方法。

カテゴリ: サーバー管理; コマンドの勉強

Fedora20にしてから妙にHDDがガリガリ言うし、
PCケースのファンがブンブンブンブン回るなあと思っててしかも随分重たいなあと思ってました。
夏で暑いからかなあとか思ってたり。

こういう時は、topコマンドよねってことで叩いたら
rsyslogデーモンがCPUリソース100%になってました。

で、しばらく解決方法がわからずとりあえずrsyslogデーモン止めちゃえってことで

 

sudo systemctl stop rsyslog

sudo systemctl disable rsyslog

にしておきました。

デスクトップ目的だからrsyslogデーモンぐらいなくてもいいやと思ってたんですが
止めてたら悔しいなあと思って検索してみました。

そしたら、今日になって何故か改善方法にたどり着いた。
参考サイト：　Bug 1047039 - rsyslog consumes 100% CPU

Fedoraのbugzillaですね。

この報告によると
（一旦sudo systemctl stop rsyslog でrsyslogを止めて
/var/lib/rsyslog/imjournal.stateを削除
デーモンを起動しなおしてみろって書いてあります。



sudo rm -Rv /var/lib/rsyslog/imjournal.state

sudo systemctl restart rsyslog

ほで、この参考サイトでもありますがこれではリソース食いはなおりましぇん。

これでダメなら/var/log/journal/*を削除（バックアップ）してrsyslogデーモンを再起動してみろと書いてあります。
（削除する前にrsyslogを止めてたほうがいい！？

コマンドで書くと



sudo systemctl stop rsyslog 

sudo rm -Rv /var/log/journal/*

sudo systemctl start rsyslog

ですね。
それでtopコマンドで見てみると
rsyslogのリソースが減るどころか見えなくなりました。
(なにも起動してなければ一番食ってるのはgnome-shellかtracker

ちゃんと直りました^^;
最後にrsyslogがシステム起動時にサービスを起動してくれるように



sudo systemctl enable rsyslog

とおまじないをかけておけばオッケーです。

念の為システム再起動した後は、



sudo  systemctl status rsyslog

と打って



rsyslog.service - System Logging Service

   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled)

   Active: active (running) since 水 2014-08-27 13:37:28 JST; 29min ago

 Main PID: 627 (rsyslogd)

   CGroup: /system.slice/rsyslog.service

           └─627 /sbin/rsyslogd -n

とrunningになっていることを確認しておきましょう。



rsyslog.service - System Logging Service

   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled)

   Active: inactive (dead) since 水 2014-08-27 14:08:07 JST; 2s ago

  Process: 627 ExecStart=/sbin/rsyslogd -n $SYSLOGD_OPTIONS (code=exited, status=0/SUCCESS)

 Main PID: 627 (code=exited, status=0/SUCCESS)



 8月 27 14:08:07 localhost.localdomain systemd[1]: Stopping System Logging S...

 8月 27 14:08:07 localhost.localdomain systemd[1]: Stopped System Logging Se...

Hint: Some lines were ellipsized, use -l to show in full.

とinactive(dead)となっているなら、
startとenableしておきましょう。
（コマンドは上にかいてあります。

ようやくリソースというかパソコンがファンブンブンが止まりました。
ちょうど今日は雨が降って気温が少し下がってるってこともあるかもだけど
こんなにパソコンって静かなのね（笑）
ところで私はrsyslogどころかsyslogがなにしてるか分かりませんから質問しないでね^^;

タグ：: 軽量化

2013年02月03日14:28

Fedoraのネットワークカードのデバイス名をeth0に戻す方法。

カテゴリ: Fedora Core; サーバー管理

Fedoraの15ぐらいからネットワークカードのデバイス名が変更されていました。
ifconfigしてみると分かりますが、

em0やp5p1等となっています。

私の環境だと



ifconfig



p5p1: flags=4163  mtu 1500

        inet 192.168.1.11  netmask 255.255.255.0  broadcast 192.168.1.255

        inet6 fe80::225:22ff:fea0:9f67  prefixlen 64  scopeid 0x20

        ether XX:XX:XX:XX:XX:XX  txqueuelen 1000  (Ethernet)

        RX packets 1556629  bytes 763755804 (728.3 MiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 1788965  bytes 946806952 (902.9 MiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

となっています。
（ネットワークカードのMACアドレスは、XXにして隠しています。）

これをeth0に戻す方法がリリースノートに載ってました。

3. Fedora の変更点 - デスクトップユーザー向け

一貫性のあるネットワークデバイス名
Fedora 18 では引き続き以前のリリースでも実装されていた biosdevname というネットワークデバイス名の命名規則が適用されます。サーバーのマザーボード上の内蔵 Ethernet は emport_number。PCI カード上の Ethernet ポートは pslot_numberpport_number のように筐体のラベルと同じような順序で命名されます。この機能を無効にしたい場合には、カーネルオプションで biosdevname=0 と指定することで無効にできます。その場合、昔から使われている ethX という名前になります

とあります。

たぶん、/etc/grub.d/以下を弄るという正しい方法があるはずなんですが、分かりません(´・ω・｀)

コメントでsawaさまからアドバイスがありました。

カーネルに与えるパラメーターは、/etc/default/grub の
GRUB_CMDLINE_LINUX」で設定できます。

GRUB_CMDLINE_LINUX="biosdevname=0"
と書いて
grub2-mkconfig -o /boot/grub2/grub.cf

ということだそうなので、



sudo vim /etc/default/grub

と設定ファイルを開き

GRUB_CMDLINE_LINUXの行末の”を削除し、
biosdevname=0”を追記します。

設定例（環境によって異なるのでそのままコピペしないように。

GRUB_CMDLINE_LINUX="SYSFONT=False rd.lvm=0 rd.dm=0 rd.md=0 rd.luks=0 LANG=ja_JP.UTF-8 KEYTABLE=jp106 rhgb quiet biosdevname=0"

そして、以下を実行してgrubの設定を反映させます。



sudo grub2-mkconfig -o /boot/grub2/grub.cf

これであとは再起動すればOKなはずです。

というわけなんで、/etc/grub2.cfgのvmlinuzの行末に biosdevname=0とすればいいと思います。

sudo grep vmlinuz /etc/grub2.cfg

linux /vmlinuz-3.7.4-204.fc18.x86_64 root=UUID=4fd12a36-b675-4300-b991-b2b7b5c8ac0c ro SYSFONT=False rd.lvm=0 rd.dm=0 rd.md=0 rd.luks=0 LANG=ja_JP.UTF-8 KEYTABLE=jp106 rhgb quiet
linux /vmlinuz-3.7.3-101.fc17.x86_64 root=UUID=4fd12a36-b675-4300-b991-b2b7b5c8ac0c ro SYSFONT=False rd.lvm=0 rd.dm=0 rd.md=0 rd.luks=0 LANG=ja_JP.UTF-8 KEYTABLE=jp106 rhgb quiet
linux /vmlinuz-3.7.3-101.fc17.x86_64 root=UUID=4fd12a36-b675-4300-b991-b2b7b5c8ac0c ro SYSFONT=False rd.lvm=0 rd.dm=0 rd.md=0 rd.luks=0 LANG=ja_JP.UTF-8 KEYTABLE=jp106 rhgb quiet
linux /vmlinuz-3.7.3-101.fc17.x86_64 root=UUID=4fd12a36-b675-4300-b991-b2b7b5c8ac0c ro single SYSFONT=False rd.lvm=0 rd.dm=0 rd.md=0 rd.luks=0 LANG=ja_JP.UTF-8 KEYTABLE=jp106 rhgb quiet
linux /vmlinuz-3.6.11-1.fc17.x86_64 root=UUID=4fd12a36-b675-4300-b991-b2b7b5c8ac0c ro SYSFONT=False rd.lvm=0 rd.dm=0 rd.md=0 rd.luks=0 LANG=ja_JP.UTF-8 KEYTABLE=jp106 rhgb quiet
linux /vmlinuz-3.6.11-1.fc17.x86_64 root=UUID=4fd12a36-b675-4300-b991-b2b7b5c8ac0c ro single SYSFONT=False rd.lvm=0 rd.dm=0 rd.md=0 rd.luks=0 LANG=ja_JP.UTF-8 KEYTABLE=jp106 rhgb quiet

なので、今使っているカーネルのバージョンを

uname -r
3.7.4-204.fc18.x86_64

と確認して、/etc/grub2.cfgのvmlinuzの行末にbiosdevname=0を追加しましょう。

例としては、こんな感じ。カーネルオプションはインストールした環境によって異なるので、
以下をコピペとかはしないように…

linux /vmlinuz-3.7.4-204.fc18.x86_64 root=UUID=4fd12a36-b675-4300-b991-b2b7b5c8ac0c ro SYSFONT=False rd.lvm=0 rd.dm=0 rd.md=0 rd.luks=0 LANG=ja_JP.UTF-8 KEYTABLE=jp106 rhgb quiet

の行末に、以下のように

linux /vmlinuz-3.7.4-204.fc18.x86_64 root=UUID=4fd12a36-b675-4300-b991-b2b7b5c8ac0c ro SYSFONT=False rd.lvm=0 rd.dm=0 rd.md=0 rd.luks=0 LANG=ja_JP.UTF-8 KEYTABLE=jp106 rhgb quiet　biosdevname=0

と変更します。

ただし、/etc/grub2.cfgを直接弄ると、起動しなくなる可能性もありますしので慎重に…
また、カーネルがアップデートされたら同じ作業をする必要があります。

たぶん、/etc/grub.d/以下を弄るという正しい方法があるはずなんですが、分かりません(´・ω・｀)

タグ：: grub2; サーバー

ブログ内の検索