lxc-start -d -n <<vmname>> でエラーが発生することがあった。 気になるところは、 /var/lib/lxc/vmtest/rootfs をマウントすると出来ないが、 マウントを外すとアタッチすることができた。 どうやら、マウントをする前にlxcをクリエイトしてしまったことが問題だった。 つまり、論理ボリューム上ではなく、サーバーのホスト内にlxcを作成してしまったため、 マウント後の /var/lib/lxc/vmtest/rootfs のディレクトリ以下は何も作成されていない状態であった。 もちろんマウントを外すと上記のディレクトリ以下にはファイルがあるためlxcがスタートできる。 なので、論理ボリューム上にlxcを作成したいなら先にマウント先のディレクトリを作ろう
作成者: roroi_ng
肌色の練習(※18禁)
恥じらいがあったものの塗ってみるとだんだん立体的になるので面白い!
もう少し明暗はっきりしてもよかった?
内容は初めてのあれみたいな感じ
linuxでOSを確認する
自分が利用しているサーバーのOSがCentOSとかubuntuとか確認したい場合がある。
これまでは下記コマンドでCentOSかubuntuかを確認していた。
CentOSの場合なら下記ファイルが存在するかしないとか
cat /etc/redhat-release
ubuntuの場合なら cat /etc/os-release
改めてググってみると下記コマンドでよかったcat /etc/issue
ただし、/etc/issueってログイン前のメッセージを表示するらしいので、
場合によっては表示されない可能性あり
ついついツインテール
今回だけは許してあげなくもないんだからね。
ツインテールといえばツンデレとか勝気ってイメージが自分のなかであります。
最近、しっかり絵を完成させることより継続することのほうが大事だからラフでも描きたいものをかくことにした。
本当は成長を妨げるんだけど、今まで一度書いたら完成させるまでアウトプットできないってのがつらかったから。まずは楽しむことを優先とした
Elastic Cacheでスケーラブル
インスタンスをスケールアウトするためにはステートレスでなければいけない。そのためにElastic Cacheにデータを一時的に保持しておく。
ステートレスとは外部からの情報のみによって出力がきまるもの。
ステートフルだとサーバーが既に保持している情報によって障害が発生するようだ。
なんだろう、オシャレ
一時創作して遊んでいたんだけど、レイヤーの基本的な部分を抜いてみたところふわっとオシャレになっていた。
なんだろう、黄色とベースとした統一感がいいのか。影が際立って立体感を見てる側の脳で保管してしまうからなのか。不思議な発見
NATからGatewayへの考え方
AWS上でルートテーブル上でローカルIPからNATを通した機器とインターネットゲートウェイに繋がる機器を作成したときに思ったこと。
NATを通す機器に対してなぜローカルIPを割り当てる必要があるか理解ができていなかった。
もっといえば、グローバルIPがあるのになぜローカルIPもついているのも理解できていなかった。
結局、NATが付いたローカルIPも機器だから当たり前なんだよね。その機器もネットが必要だから。
だからルーターとかもローカルIPが割り当てられていると思う。
Unexpected condition from IMAP server, closed or corrupt connection to IMAP. Possible mailbox corruption.
roundcubeの検索フォームが正常に機能せずにエラーとなり、
タイトルのエラーがroundcubeのディレクトリ以下にerror.logとして表示されていた。
上記サイトを参考にコマンドを実行したところ、検索フォームが回復した。
コマンドの例
/usr/local/cpanel/scripts/remove_dovecot_index_files --user username(対象のアカウント名) --verbose
名前ベースとIPベースの違い
Apacheのconfの説明で名前ベースとIPベースってあるけど、二つの役割の違いってなんだと思って確認してみた。
■名前ベース
一つのサーバーに一つのIPを使って複数のドメインを用いることで複数のwebサイトを運営している。
■IPベース
1つのIPにつき、ドメインを1つ割り当てること。
上記については、
客の立場からするとIPを一つ購入するのにお金がかかるし、IPを一つ割り当てるときにDNSを切り替えると変更までの時間がかかるから名前ベースは便利だなという印象。
なお、SNIのことは名前ベースのことと認識
■以下参考
名前ベースの場合のソース
<VirtualHost *:80>
ServerName web.test.jp
ServerAdmin webmaster@web.test.jp
DocumentRoot /var/www/virtual/test
<VirtuialHost>
2つめのソース
<VirtualHost *:80>
ServerName web.test2.jp
ServerAdmin webmaster@web.test2.jp
DocumentRoot /var/www/virtual/test2
<VirtuialHost>
IPベースのバーチャルホスト
Listen 192.168.1.10:80
Listen 192.168.1.11:80
<VirtualHost 192.168.1.10:80:80>
ServerName web.test.jp
ServerAdmin webmaster@web.test.jp
DocumentRoot /var/www/virtual/test
<VirtuialHost>
<VirtualHost 192.168.1.11:80:80>
ServerName web.test.jp
ServerAdmin webmaster@web.test2.jp
DocumentRoot /var/www/virtual/test
<VirtuialHost>
ボリュームグループの存在について
LVM pv,vg,lv といろいろあってわけわからなかったけど、下記サイトのおかげでやっとわかった。
https://piro791.blog.ss-blog.jp/2008-11-04
pvあればそのままlvしたらいいと思ってたけど、vg作らないと仮想ディスクとならないってこと。仮想ディスクをパーティションで切るのはlvってこと。
pvもいらないと思ってたけど、vgが物理ボリュームと認識するために必要なものと認識する。