requirettyを全力で回避した話 | 黒曜の吹き溜まり
会社で作業をするために使うスクリプトをOCamlで書いてやりました。 本番のログ取得作業が面倒すぎたので、一括取得するスクリプトをOCamlで書いて配布したアカウントがこちらになります。omakeではなくOCamlMakefile使ってるから問題ないでしょ？(錯乱 — 黒曜 (@kokuyouwind) July 24, 2014 で、この過程でrequrettyに苦しめられたのでその辺のメモ。 requiretty外せないサーバ上でsudoしてからコマンド実行しないといけない、呪われた運命を背負った ”>魔法少女 開発者の助けになればな、と。 うちの会社で開発者が本番サーバに入るためには、一旦踏み台サーバを介する必要があります。 また、踏み台サーバから本番へ入るためのssh鍵はsuperユーザしか持っていないため、一旦 を行う必要があります。 あ、ちなみにsuperユーザはrootという
root 権限の必要なディレクトリに対してrsync する - ´・ω・)＜ときどき書くよ
CentOS のApache でDocumentRoot とされている/var/www/html をサーバ間で同期するために % rsync -avz -e ssh --delete /var/www/html foo@example.com:/var/www/htmlとrsync を実行しても、foo に/var/www/html への書き込み権限がないため成功しない。 # PermitRootLogin yes な方は勝手にどうぞ。 NFS が使えれば手っ取り早いのだが、一つの解決策として example.com に以下のスクリプトを置き(/home/foo/rsync.sh とする) #!/bin/sh /usr/bin/sudo /usr/bin/rsync $* visudo で foo ALL=(ALL) NOPASSWD: /usr/bin/rsync と設定しておく。 あと
＠IT：止められないUNIXサーバの管理対策 第5回 （3） ～管理者権限の制限のためのsuとsudoの基本～
※ご注意 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。 前回は、すべてのコマンドが使用できてしまう特権ユーザー（スーパーユー ザー）の利用制限について説明した。今回は、引き続き特権ユーザーが通常行うsuのセキュリティ上の問題点やsudoの基本的な使い方について紹介する。 suの問題点 suコマンドは、再ログインになしにrootに限らず任意のユーザーにスイッチすることができるという、とても便利なコマンドだ。しかし、そんなsuコマンドには、以下に示すようなことが懸念されている。 ●rootのパスワードを入力する必要がある suコマンドは、実行時にスイッチするユーザーのパスワードを入力する必要がある。例えばtelnetでリモートログ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
