Ubuntu でファイル共有などファイルシステムを mount するとき、 sudo を使うのでマウントポイントが root の持ち物になってしまう。 するとせっかくマウントしたのに書き込もうとするたびに sudo しなきゃならなくなり、あまりにも馬鹿ばかしい。 対処法は、 -o オプションで uid と gid を渡すこと。（あるいは sudoers で mount 権限を追加するってのもアリだよね…） $ # samba 共有をマウントする例 $ sudo mount -t cifs\ -o uid=1000,gid=1000,username=<your account>\ //server/share dir # enter your file share passwordただ、ログインしているユーザーのユーザー ID やグループ ID がどちらも 1000 固定だなんて仮定するの
ども、あらためて Consul を勉強している cloudpack の かっぱ (@inokara) です。 はじめに consul exec や consul watch あたりを色々と試してみる。 参考 consul command オーケストレーションツールとしてのConsulの使い方 【Consul】 0.4の新機能（参考訳） consul exec ざっくりホワっと クラスタ内のノードにて一斉にコマンドを実行させることが出来るという脳筋な自分にはとても嬉しいコマンド。 トライ 例えば consul クラスタ内のノードでリーダーノードの確認をしてみる。 $ consul exec curl -s -X GET http://localhost:8500/v1/status/leader ip-xxx-xx-xx-36: "xxx.xx.xx.36:8300" ==> ip-xxx-
環境 ubuntu 14.04 ansible: 1.6.1 vagrant: 1.6.2 sudo可能なユーザを追加するplaybookの例 --- - hosts: webservers sudo: true vars: # created with: # openssl passwd -salt scibloaddx -1 ******* password: $1$tekitoun$t293q2jBZPnzIljKNdGK.. tasks: - user: name=yamada password={{password}} shell=/bin/bash state=present append=yes groups=sudo
例えば subversion サーバを設定するとき、subversion グループを作成する。 % sudo groupadd subversion ここで、作成したグループをユーザーに追加するのに、決して usermod -G を使ってはいけない。 % sudo usermod -G subversion user # ダメ！ 「確かに」これでユーザーは subversion グループに設定できる。だが誤った使い方である。何がいけないか。 既に設定されていた他のグループの設定が全部飛ぶのだ！ 特に怖いのが、個人でUbuntuを使っている場合に唯一のユーザである本人が admin グループから外れること。 不具合に気がついて vigr で修正しようにも、sudo が利かない！ もちろんリカバリーモードで復旧は可能*1だし（/etc/group- というバックアップファイルが作られるようだ）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
