More from: linux

VAIOにubuntuを入れてみた

昨日書いたけど、VAIOノート「VGN-G2AAPS」にubuntuをインストールしてみた。
メモリが1.5GBしかないので、インストールしたのは日本語 RemixのUbuntu 14.04の32bit版。
インストール自体はイメージを焼いたDVDを入れて起動し、あとは殆ど画面の指示に従って行えば特に問題無く出来た。
動作も古いハードウェアの割にはスムースで、FirefoxやLibre Officeのアプリの動作もそれほど重いとは感じなかった。
元々それほど重たい処理をさせるつもりの無いサブのサブみたいなノートだから、これはこれでそこそこ使えそうだな。

←クリックしてくれると嬉しいです。

VAIOにubuntu

ひょんなことで手元に来たSONYの小型ノートPC「VGN-G2AAPS」。
インストールされているOSがWindowsXPなので、このままではちょっと使えない。
そこでデスクトップ用のLinuxでも入れてみようかと思い、ちょっと試してみた。
試してみたのはubuntuの15.10で、配布サイトからDVDイメージをダウンロードしてDVDに焼き、VAIOに入れてDVDから起動してみた。
ubuntuはインストールDVDから起動すると”お試し”が出来るので、先ずはインストールせずに試してみたところ、Xの起動に時間がかかったがこれはモジュールをDVDから読み込んでいるためである程度は仕方が無い。
一度Xが起動するとワードプロセッサー(Libre Office Writer)も、ブラウザ(Firefox、ubuntu browser)もそこそこ動いてくれた。
なにせCPUがCore2DuoのU7600(超低電圧版1.2GHz動作:Meromコア)でメモリが1.5GB(オンボード512MB、増設1GB)という一昔も二昔も前のスペックなのに、そこそこ動いてくれるのは良い。
今回試したのは64bit版だけど、メモリが1.5GBしか無いので32bit版でも良い(というかメモリ2GB以下は32bit版が推奨されている)から、インストールするなら32bit版だろうなぁ。
ただ、日本語 RemixのイメージはUbuntu 14.04までしか無く、それより新しい15.10とかは64bit版しか無い。
ただサポート期間は14.04のほうが長く2019年4月まで(15.10は2016年7月まで)らしいので、入れるならこれなのかな?

←クリックしてくれると嬉しいです。

ユーザー設定の移行(備忘録)

仕事で使っているサーバの負担が大きくなってきたので、処理を分散させるために仮想でもう一台作った。
新しいサーバに一部の処理を移行させるのだけど、やっているのがメールの代理受信なので、ユーザーデータも移行しなければならない。
スプールの中身は移さずに全て受信後に新しいサーバに移行して貰うつもり。
なので新しいサーバでユーザーを新たに登録する作業が必要で、いちいち手作業でやっていてはミスが出るので元のサーバのユーザー情報を元に登録用のスクリプトを作った。
最初に旧サーバから/etc/passwdファイルを新サーバにコピーしておく(実際には/etc/alisesや/etc/groupファイルもコピー)。
# ”awk -F : ‘{print “/usr/sbin/useradd -u ” $3 ” -g ” $4 ” -d ” $6 ” ” $1}’ passwd > hoge”
そうして上のコマンドを実行するとファイル”hoge”の中に
/usr/sbin/useradd -u 501 -g 501 -d /home/user1 user1
のような登録用のコマンドが作られるので、後はこれを実行すればユーザーの登録が出来る(移行させたくないユーザーの分は行を削除するかマスクしておけばOK)。
問題はパスワードの設定で、一つ一つ手で入力していたら大変(ユーザー数が三桁あるので)。
これをなんとかバッチで流し込めないか現在考え中・・・
これも旧サーバの/etc/shadowファイルから切り出して流し込めれば楽なんだけどなぁ・・・
一度
useradd -u 501 -g 501 -d /home/user1 -p ”切り出したパスワード文字列(暗号化済み)” user1
でやってみたらユーザーは登録出来るけどパスワードは正しく設定されなかったorz

さて、どうしたものか???

←クリックしてくれると嬉しいです。

”ゴミ箱”機能を追加した

昨日ファイルサーバ内で大量のファイルを移動されて見えなくなった対策の一部として、ファイルサーバにゴミ箱機能を追加した。
ファイルサーバではsambaを使っているので、次のページ
「Sambaでごみ箱を使うには(Red Hat Linux編)」(@IT)
を参考に、/etc/samba/smb.confに記述を追加してユーザーが削除したファイルは実際に削除されずに指定したディレクトリに移動するようにした。
移動する際に同じ共有ドライブに移動されるとディスクスペースを圧迫してしまうので、容量に余裕のあるパーティションにゴミ箱用のディレクトリを作り、各共有ディレクトリのルートにはそこへのシンボリックリンクを張った。
試しにファイルを削除してみると無事にそのディレクトリにファイルが移動したので、ゴミ箱ディレクトリは同じファイルシステム上に無くても良いみたい。
後は削除してから一定以上の日数が経過したファイルの自動削除の仕掛けを作ればOKかな?

←クリックしてくれると嬉しいです。

たまにしか書かないと忘れるなぁ(汗)

サーバーのログの中から特定の文字列を探すのにコマンドラインから
”grep ほげ げしょ | awk ‘{print $8}’ | uniq
と書くところを、最初は
”grep ほげ げしょ | sed ‘{print $8}’ | uniq
と書いてしまい
”sed: -e 表現 #1, 文字数 3: コマンドの後ろに余計な文字があります”
というエラーを返されてしまった(汗)。
それを見ておかしいな?と思って直したのが
”grep ほげ げしょ | sed {print $8} | uniq
で、これでも同じエラーが出る(当たり前)。
そもそも”sed”を使うつもりは無く”awk”と書いているつもりなので、そこが間違っているとは気付かなかった。
2回目のエラーでようやくawkではなくてsedと書いていることに気付いて直したと言う(汗)。
いやぁ、しばらくぶりに書くと忘れてるねぇ・・・

←クリックしてくれると嬉しいです。

なんとかなりそうだ・・・

メールスプールが満杯で新たなメールが受け取れ無くなったアカウントのスプールファイルを手動で編集して書き戻したところ、ファイルサイズが1割ほど小さくなっていた。
その状態でnPOPを使ってログインしてみると幸いにもタイムアウトを起こさなかったので、サイズが大きくて不要なメールを選択して削除した。
その結果最終的にはファイルサイズが1/4以下になったので、これならユーザーのメーラーでもタイムアウトせずに読める筈。
ただ、配信不能でmailキューに溜まっているのが200通以上あるので、現在はこれのフラッシュ中。
フラッシュは
sendmail -q (好みで”-v”オプションを付けるのも可)
で行っているけど、溜まっていたキューの中にも大きくて不要なのがありそうだから、終わったら再度整理しておかないとならないかな?(汗)

それにしても仕事に出てるんだったら休みの日以外はメールを読んでくれよなぁ・・・いや!読まなくてもいいからサーバーから取りこんでサーバー上のは削除してくれよ・・・

つーか、メールシステムを全面的に変更したいな(汗)

←クリックしてくれると嬉しいです。

sambaサーバーに接続出来ない???

職場のPCの一台をファイルサーバーに接続して欲しいとの依頼があったので、接続用のユーザーアカウントを作ってクライアントPCの設定を行った。
ところがパスワードが違うということでサーバーに接続を拒否されてしまう。
パスワードの設定を間違ったかと思い、サーバー側で再度パスワードの設定をやり直し、念のため自分が普段使っているPCから新しいユーザーで接続を試すと接続出来た。
これで大丈夫と思って再度目的のPCの設定を行ったが、やはりパスワードエラーではじかれる。
サーバー側のログを見ても認証失敗のメッセージが出ているので、接続には行っているのは確かでネットワークの問題では無さそう。
さて、一体どういう理由で認証に失敗しているんだろうな???

←クリックしてくれると嬉しいです。

またまたgssftpの設定(汗)

またまた現場のサーバーにてftpサーバーを動作させる必要が出来た。
まずは明日行く福岡の現場にあるWindowsサーバーでは既にftpサーバーを動作させていると思いこんでいたら、実は動作しておらず接続拒否をされてしまう。
そこでIISマネージャーから設定しようとしたら、IISそのものが動作していない・・・
仕方が無いのでIISも含めてftpサーバーの設定を行った。

もう一か所はLinuxサーバーでパッケージとしてはgssftpなので、/etc/xinetd.d/gssftpファイルを編集して最後の行の
disable = no

disable = yes
に書き換えてxinetdを再起動・・・で済む筈が、これだけではユーザー認証で弾かれてしまうので、先月二十日に書いた記事「gssftpの設定」を参考にさらに2行前の
server_args = -l -a

server_args = -l
に書き換えてxinetdを再起動。
これで通常通りにログインが可能になった。

←クリックしてくれると嬉しいです。

ftp接続でのpassive modeの切り方

ftpを使ってのデータのやりとりで、ファイアーウォール等では20番及び21番ポートを開けているにもかかわらず、何故かデータの送受信が出来ないことがある。
最初の接続及びユーザー名を使っての認証までは行えるのに、データを送る(もしくは受け取る)操作(getもしくはput)をしても
ftp: connect: Connection timed out
と出てしまい送受信が出来ない。
こんな時はPassive Modeになっているのではないだろうか?
実際私も職場と現場のサーバー同士でデータの送受信を行おうとして上手くいかなかったことがあり、そういう時は決まってPassive Modeになっていた。
Passive Modeで送受信する時は使われるポートがその時の環境で変化するために、場合によってはファイアーウォール等で閉じてあるポートを使うことになり、当然ながらパケットが通らずにタイムアウトを起こすことになる。
#Passive Modeの場合はlsコマンド等の結果が返ってくるポートも不定なので同様にタイムアウトを起こしてしまう。
この場合はPassive Modeをオフにすることでftpクライアントはデータ転送に20番ポートのみを使うようになるので、問題無くデータを送受信できるようになる。
Linux標準のftpクライアントでは
ftp>Passive off
としてやることでPassive Modeをオフにすることが出来る。
Windows用のクライアントソフトの場合はソフトにより設定の方法が異なるので、ここでは書かないけど、大抵はPassive Modeをオフにすることが出来る筈(Windows7のコマンドプロンプトで使えるftpクライアントではpassiveコマンドが無くて設定できなかった)。
接続もログインも出来るのにデータの送受信でタイムアウトになる場合はお試しあれ。

←クリックしてくれると嬉しいです。

gssftpの設定

何年か前に遠隔地にサーバーを設置したが、その現場にちょっと大きめのデータを送る必要が出来た。
CD-Rに焼いて送ろうかと思っていたが、Linuxサーバーがあるのでftpで送れば良いのでは?と思い試して見た。
手元のPCから直接FTP接続をしてみたが、ルーターでブロックされて駄目(汗)。
仕方がないので一度近くのサーバーにアップして、そこから接続すると相手サーバーにはじかれてやはり駄目。
これは相手側サーバーでftpサービスを動作させていないためで、サービスを動作させてやればOKと思い設定してみた。
相手サーバーにインストールされていたftpパッケージはタイトルにもあるgssftpなので、設定ファイルは”/etc/xinetd.d/gssftp”というファイル。
この中に記述されている
disable = yes

disable = no
に書き換えてから
xinetdを再起動(/etc/rc.d/init.d/xinetd restartを実行)。
早速接続してみると、接続は出来るが
334 Using authentication type GSSAPI; ADAT must follow
GSSAPI accepted as authentication type
GSSAPI error major: Unspecified GSS failure. Minor code may provide more information
GSSAPI error minor: No credentials cache found
GSSAPI error: initializing context
GSSAPI authentication failed
334 Using authentication type KERBEROS_V4; ADAT must follow
KERBEROS_V4 accepted as authentication type
Kerberos V4 krb_mk_req failed: You have no tickets cached
Name (localhost:hoge):
530 Must perform authentication before identifying USER.
Login failed.
Remote system type is UNIX.
Using binary mode to transfer files.
というエラーが出てログインできない。
どうもユーザー認証の方法に問題があるようだけど、よく判らないのでググってみると解決方法が見つかった。
設定ファイルにある
server_args = -l -a
の行から”-a”を削除して
server_args = -l
としてxinetdを再起動すると無事にログインすることが出来た。

←クリックしてくれると嬉しいです。