底辺でもがくITエンジニア
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
Windowsでは標準のツールとしてディスクデフラグがあります。
断片化を解消しアクセス効率を高めようとするものですが･･･
ではLinuxは？
必要ないらしいです。
なぜならば、断片化するようなシステムになっていないからだそうです。
http://www.obenri.com/_dialy/linux_defrag.html
http://www.geekpage.jp/blog/?id=2006/8/22
http://kesuike-kisamaya029.hp.infoseek.co.jp/com/dfrg.html
断片化を解消しアクセス効率を高めようとするものですが･･･
ではLinuxは？
必要ないらしいです。
なぜならば、断片化するようなシステムになっていないからだそうです。
http://www.obenri.com/_dialy/linux_defrag.html
http://www.geekpage.jp/blog/?id=2006/8/22
http://kesuike-kisamaya029.hp.infoseek.co.jp/com/dfrg.html
PR
Windows 2003 Serverでは(おそらく2008も変わらない)dcpromoコマンドを使いanswerファイルを読み込ませることによってドメインコントローラの昇格、降格をコマンドで行えます。
とりあえず今回昇格についてあまりに情報が少なかったので、メモ書きします。
参考URL
http://support.microsoft.com/kb/223757/ja
http://www11.ocn.ne.jp/~material/windows/3/3-1/index.htm
http://blogs.msdn.com/emberger/archive/2008/12/13/automating-wss-v3-moss-2007-development-environment-setup-part-iv-unattended-dc-promo.aspx
http://www.geocities.jp/ex709/2003ad.htm
とりあえず今回昇格についてあまりに情報が少なかったので、メモ書きします。
参考URL
http://support.microsoft.com/kb/223757/ja
http://www11.ocn.ne.jp/~material/windows/3/3-1/index.htm
http://blogs.msdn.com/emberger/archive/2008/12/13/automating-wss-v3-moss-2007-development-environment-setup-part-iv-unattended-dc-promo.aspx
http://www.geocities.jp/ex709/2003ad.htm
♥ 続きはこちらです
iptablesの設定の重要さはいうまでもありません。
Linuxを運用するならサーバ、デスクトップ問わずある程度のセキュリティを考える必要性があるでしょう。
そこで色々と設定例を出したいのですが、あまり時間もないせいで出来てない
と、いうことで設定時に役に立ちそうなリンク集を貼っておきます。
設定例
http://linux.shoukun.com/security/iptables.htm
http://d.hatena.ne.jp/Ubuntu/20080128/1201462048
http://arisonsvr.org/web/maincontents/serverset/iptables/iptable.html
http://www.nina.jp/server/redhat/iptables/iptables.html
iptables概要、コマンドマニュアル
http://cyberam.dip.jp/linux_security/iptables/iptables_main.html
http://www.linux.or.jp/JM/html/iptables/man8/iptables.8.html
Linuxを運用するならサーバ、デスクトップ問わずある程度のセキュリティを考える必要性があるでしょう。
そこで色々と設定例を出したいのですが、あまり時間もないせいで出来てない
と、いうことで設定時に役に立ちそうなリンク集を貼っておきます。
設定例
http://linux.shoukun.com/security/iptables.htm
http://d.hatena.ne.jp/Ubuntu/20080128/1201462048
http://arisonsvr.org/web/maincontents/serverset/iptables/iptable.html
http://www.nina.jp/server/redhat/iptables/iptables.html
iptables概要、コマンドマニュアル
http://cyberam.dip.jp/linux_security/iptables/iptables_main.html
http://www.linux.or.jp/JM/html/iptables/man8/iptables.8.html
windows環境で構築や開発を行っているとたまにサービスが起動できないことがある。
たいていサービスの起動ユーザなんてSYSTEMユーザが担当するものですが、開発環境によってはローカルユーザでコントロールすることもあるでしょう。
その場合はサービス起動のトラブルに悩まされることも多いかと思います。
たいていサービスの起動ユーザなんてSYSTEMユーザが担当するものですが、開発環境によってはローカルユーザでコントロールすることもあるでしょう。
その場合はサービス起動のトラブルに悩まされることも多いかと思います。
♥ 続きはこちらです
LinuxをホストとしてNICを2枚用意する。
その上で1枚目のNICを通して2枚目のNICを橋渡しします。
その際不必要なパケットをなるべく破棄する、またはパケット状況を監視するサーバを構築してみたいと思います。
通常はNICを2枚用意するのでノートブックでは実現性が薄いですし、ほぼルータとしての役割を果たすことになるのでNICの向こうで作業を行う場合、連動して稼動している必要があります。
ですので、実稼動させる環境は個人ではさほど無いと思いますが、機能があるなら何かの役に立つと思いますし、やってみようよ、ってところでしょうか。
その上で1枚目のNICを通して2枚目のNICを橋渡しします。
その際不必要なパケットをなるべく破棄する、またはパケット状況を監視するサーバを構築してみたいと思います。
通常はNICを2枚用意するのでノートブックでは実現性が薄いですし、ほぼルータとしての役割を果たすことになるのでNICの向こうで作業を行う場合、連動して稼動している必要があります。
ですので、実稼動させる環境は個人ではさほど無いと思いますが、機能があるなら何かの役に立つと思いますし、やってみようよ、ってところでしょうか。
♥ 続きはこちらです
、色々なサイトを参考にしてもよく理解できないんですよね。。。
)。
業務にかかわらず個人でも行うかと思いますが、PCデータのバックアップは大切です。
特にOSレベルのフルバックアップも行うことがあるでしょう。
取得したバックアップは多くは使われることはありません。
使われることが無いからこそ、個人レベルではバックアップはおろそかにしがちです。
まぁ、このように話してしまうと元も子もないですが、ではどのような場合に使うかと言うと、良くあるのが試験環境で使われます。
（そのほかについてはリンク先などを参照）
本システムが稼動するまでは本稼動において十分な稼動が出来ることを証明するためにいくつもの試験工程を踏み、最終リリースにいたります。
その試験工程においてテストする業務によっては他の業務と同一で試験をすることが出来ない、又はリスクを負うことが発生する場合、専用にサーバを設ける必要があります。
(本稼動時には一つのサーバに全ての業務を載せる場合)
そうなった場合、それまでの土台である制御部分は共通でなければならず、再構築には費用も時間も手間もかかります。
これを一括で解消できるのは現在使用しているサーバのミラーリングです。
ミラーリングすることにより確実に同じ環境でテストする業務のみを変更してテストを実施できるのです。
(通常設計の段階で決定してると思いますので、サーバ自体はあらかじめ余裕があると思います)
このように試験にあわせて都合よく制御基盤を構築できるミラーリングバックアップですが、気をつけなければならないこともあります。
それは、2台以上にデータを復元する場合です。
これを行ってしまうと、OSや、各アプリケーション、業務が保持する一意の値もコピーされることとなり、それらを参照してサーバ間通信を行う場合、正常に動作できなくなってしまいます。
特に同じネットワークに復元したサーバを2台設置すると、間違いなくIPアドレスが同一になってしまうため、通信障害なります。
さらに場合によってはMACアドレスもコピーされてしまうのでこれを参照してサーバ間通信を図っている場合も単純にIPアドレスの変更だけでは解決できなくなってしまいます。
バックアップを復元したサーバ同士での通信障害の場合はこれらを疑ってみては?
通信障害なので多くはNICの再起動、再インストールで解決できると思います。
特にNLBは特別な値を見ているようですので、注意が必要だと思います。
※文中の文言はかなり砕けた表現を使っています。
当たらずとも遠からずな文言は無視してください、細部にわたる突っ込みは荒らしとみなします。
明らかに間違った表現はご指摘ください。
特にOSレベルのフルバックアップも行うことがあるでしょう。
取得したバックアップは多くは使われることはありません。
使われることが無いからこそ、個人レベルではバックアップはおろそかにしがちです。
まぁ、このように話してしまうと元も子もないですが、ではどのような場合に使うかと言うと、良くあるのが試験環境で使われます。
（そのほかについてはリンク先などを参照）
本システムが稼動するまでは本稼動において十分な稼動が出来ることを証明するためにいくつもの試験工程を踏み、最終リリースにいたります。
その試験工程においてテストする業務によっては他の業務と同一で試験をすることが出来ない、又はリスクを負うことが発生する場合、専用にサーバを設ける必要があります。
(本稼動時には一つのサーバに全ての業務を載せる場合)
そうなった場合、それまでの土台である制御部分は共通でなければならず、再構築には費用も時間も手間もかかります。
これを一括で解消できるのは現在使用しているサーバのミラーリングです。
ミラーリングすることにより確実に同じ環境でテストする業務のみを変更してテストを実施できるのです。
(通常設計の段階で決定してると思いますので、サーバ自体はあらかじめ余裕があると思います)
このように試験にあわせて都合よく制御基盤を構築できるミラーリングバックアップですが、気をつけなければならないこともあります。
それは、2台以上にデータを復元する場合です。
これを行ってしまうと、OSや、各アプリケーション、業務が保持する一意の値もコピーされることとなり、それらを参照してサーバ間通信を行う場合、正常に動作できなくなってしまいます。
特に同じネットワークに復元したサーバを2台設置すると、間違いなくIPアドレスが同一になってしまうため、通信障害なります。
さらに場合によってはMACアドレスもコピーされてしまうのでこれを参照してサーバ間通信を図っている場合も単純にIPアドレスの変更だけでは解決できなくなってしまいます。
バックアップを復元したサーバ同士での通信障害の場合はこれらを疑ってみては?
通信障害なので多くはNICの再起動、再インストールで解決できると思います。
特にNLBは特別な値を見ているようですので、注意が必要だと思います。
※文中の文言はかなり砕けた表現を使っています。
当たらずとも遠からずな文言は無視してください、細部にわたる突っ込みは荒らしとみなします。
明らかに間違った表現はご指摘ください。
windowsにはコマンドと呼ばれるCUIを用いて処理を行うファイル(バッチファイル)を作成することが出来ます。
今回のお話は初心者向けではなくある程度バッチファイルの作成が出来る方、タイトルでお悩みの方がいれば参考にしていただければと思います。
2009年02月22日修正
今回のお話は初心者向けではなくある程度バッチファイルの作成が出来る方、タイトルでお悩みの方がいれば参考にしていただければと思います。
2009年02月22日修正
♥ 続きはこちらです
さて、PostgreSQLのインストールも完了し、初期設定も完了しました。
次はDBユーザの作成をします。
DBユーザとは…
DBとはそもそもデータベース、つまりさまざまなデータの集合体です。
そのデータはいったいどういうものが多いでしょうか。
それはシステムによって異なりますが、少なくとも個人情報や、金銭的な帳票データなどが多いです。
つまりDBに格納されるデータはそのシステムの意味そのものであることが多いのです。
そんなシステムの中心に立つべきシステムを誰でもアクセスできる状態にしておいてよいものでしょうか。
あまりよろしくないですね。
そこでDBにアクセスできる状況を制御するためにも行うのが、DBユーザの作成です。
PgにはこのDBユーザのみしかアクセスできませんのでPgを使うユーザをあらかじめ定義しておくのがいいでしょう。
DBユーザを作成するには…
DBユーザを作成するには新規ロールを作成する権限を持つDBユーザしか行えません。
初期の状態で新規ロールを作成する権限を持ち合わせているのは「postgres」のみです。
ですのでpostgresユーザにスイッチし、DBの管理権限を与えてあげなければなりません。
postgresユーザはパッケージマネージャーを使用してインストールを行っているのであればユーザも自動的に作成されているはずです。
ですのでまずはrootユーザにてpostgresのログイン設定を行います。
ログイン設定といっても初期の状態ではパスワードの設定がなされていないために、ログインできないというだけですのでpostgresユーザにパスワードを設定してあげます。
# passwd postgres
ユーザを作成する準備はこれでOKです。
もしpostgresユーザ自体がいなかったらユーザを作成してあげます。
ロールとは…
ロールとはほぼイコール的にDBユーザということになります。
権限も踏まえユーザ単位でDBでの作業をどの程度できるのか、決定しますのでその単位をロールと呼びます。
詳細はググっていただければ難しいことがちらほら出てきます。
ここではPgに限らず、管理していく上で必要なことだけを記載します。
ユーザを作成する。
MySQLとは違いPgはPgにアクセスするということがありません。
Pgの中のDBに直接アクセスします。
MySQLなどはまずはMySQLというシステムにアクセスし、そこから使用するDBを指定してそのDBで作業を行いますが、PgはPgのシステムにアクセスした時点でDBを指定するのです。
と、言うことなので、PgにアクセスするときはPgで作業することが前提になってきます。
それ以外の作業、Pgにアクセスする段階の作業などは通常のコマンドラインから実行します。
$ createuser USER_NAME
コマンド発行後は３つの質問がされます。
新しいロールをスーパーユーザとしますか? (y/n)
新しいロールにデータベース作成権限を与えますか? (y/n)
新しいロールにロールを作成する権限を与えますか? (y/n)
それぞれ必要に応じて権限を与えてください。
システム上postgresユーザがすべての権限を持っているのは知られているのでそれ以外にスーパーユーザ権限を持っているといいですね。
もちろんpostgresユーザはその後はお役ごめんです。
そのほかの第二ユーザはとりあえずスーパーユーザとはせず、DB作成権限は必要に応じて、新しいロールの作成も通常スーパーユーザが他にいるのならば必要ないですね。
第二ユーザがどうしても作業するに当たってスーパーユーザ権限を手に入れなければならない場合、そのとき権限を変更してあげればいいと思います。
変更方法はこちらのサイトが参考になります。
次回は実際にDBを作成していきます。
♥ 雑談話はこちら
データベース（以後DB）は今や（昔から？）必須のシステムです。
どのシステムにかかわってもDBだけは存在するといってもよいでしょう。
そのためDBについて知識を得ておくということは、とても重要なことです。
ここでは一般的なLinuxで導入できるPostgreSQL（以後Pg）の導入について触れます。
Pgの導入のメリットとしては初期設定が非常に簡単で、ユーザの管理もわかりやすく容易という点にあると思います。
基本的なコマンドリファレンスはPgであろうと、MySQLであろうとORACLEであろうと大きく変わったりはしませんので、はじめてDBというシステムに触れるのであれば、Pgはお勧めです。
Pgのインストール
今はパッケージの管理が容易にできるパッケージマネージャーがあると思いますのでせっかくだから使いましょう。
Debian系
# apt-get -y install postgresql postgresql-server
RedHat系
# yum -y install postgresql postgresql-server
今はFedoraやUbuntuはGUIからでも可能でしょう。
多分その場合はpostgresqlのみを指定すれば依存関係すべてはいると思います。
とにもかくにもPgの導入に限らずパッケージの導入はこれでいけます。
まぁ、ここを見ている人は個人でしょうから、ネットワークが外部から隔離していないでしょうから無理してコンパイルから入る必要はないと思います。
ついでにPgの場合は初期設定も容易なので記載します。
初期設定を行う場合は・・・
RedHat系の場合
# /etc/init.d/rc.d/postgresql start
ようはサービスを起動するってことですね。
これだけで勝手に初期設定を行ってくれます。
ただし、外部からアクセスしたりする場合は別途、設定ファイルを書き換える必要があります。
参照
http://www.miloweb.net/postgresql.html
ただ、バージョンが古いみたいで、どうもあたしの設定では当てはまらないのでまた、正確な情報がわかったら記載します。
とりあえずPgの導入は以上です。
どのシステムにかかわってもDBだけは存在するといってもよいでしょう。
そのためDBについて知識を得ておくということは、とても重要なことです。
ここでは一般的なLinuxで導入できるPostgreSQL（以後Pg）の導入について触れます。
Pgの導入のメリットとしては初期設定が非常に簡単で、ユーザの管理もわかりやすく容易という点にあると思います。
基本的なコマンドリファレンスはPgであろうと、MySQLであろうとORACLEであろうと大きく変わったりはしませんので、はじめてDBというシステムに触れるのであれば、Pgはお勧めです。
Pgのインストール
今はパッケージの管理が容易にできるパッケージマネージャーがあると思いますのでせっかくだから使いましょう。
Debian系
# apt-get -y install postgresql postgresql-server
RedHat系
# yum -y install postgresql postgresql-server
今はFedoraやUbuntuはGUIからでも可能でしょう。
多分その場合はpostgresqlのみを指定すれば依存関係すべてはいると思います。
とにもかくにもPgの導入に限らずパッケージの導入はこれでいけます。
まぁ、ここを見ている人は個人でしょうから、ネットワークが外部から隔離していないでしょうから無理してコンパイルから入る必要はないと思います。
ついでにPgの場合は初期設定も容易なので記載します。
初期設定を行う場合は・・・
RedHat系の場合
# /etc/init.d/rc.d/postgresql start
ようはサービスを起動するってことですね。
これだけで勝手に初期設定を行ってくれます。
ただし、外部からアクセスしたりする場合は別途、設定ファイルを書き換える必要があります。
参照
http://www.miloweb.net/postgresql.html
ただ、バージョンが古いみたいで、どうもあたしの設定では当てはまらないのでまた、正確な情報がわかったら記載します。
とりあえずPgの導入は以上です。
♥ 雑談