![Unixoidデスクトップの展開に関するベストプラクティスと今後の計画は何ですか？ [閉鎖]](https://linux33.com/image/17090/Unixoid%E3%83%87%E3%82%B9%E3%82%AF%E3%83%88%E3%83%83%E3%83%97%E3%81%AE%E5%B1%95%E9%96%8B%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E3%83%99%E3%82%B9%E3%83%88%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9%E3%81%A8%E4%BB%8A%E5%BE%8C%E3%81%AE%E8%A8%88%E7%94%BB%E3%81%AF%E4%BD%95%E3%81%A7%E3%81%99%E3%81%8B%EF%BC%9F%20%5B%E9%96%89%E9%8E%96%5D.png)
私は非営利の伝播天文台のためにLinuxデスクトップを設定してきました。私としては、集中型ログイン、ホームディレクトリなどを備えた複数の同じシステムを「配布」することについて考えなければならなかったのは今回が初めてです。私はおそらく、反直感的に「すべてがテキストである」という哲学が必ずしもこの作業を簡単な作業にするわけではないことをすぐに認識していました。
私の場合は、すべてのコンピュータにUbuntu 10.04 LTSをインストールします。インストール後に設定ファイルを変更し、ソフトウェアをアンインストールしてインストールし、背景画像やブラウザのブックマークなどの一部のファイルをサーバーからコピーするカスタムスクリプトを実行しました。しかし、私の問題は展開とは無関係だと思います。
質問
私は主に2つの問題に直面しました。まず、ツールと構成ファイルはディストリビューションとバージョンによって一貫性がなく、第二に、いくつかの重要なソフトウェアは、シンプルで直感的な方法で設定ファイルに設定を公開しませんでした。
私が意味するものを説明するために、2つの簡単な例を見てみましょう。
このifconfigツールは交換中ですip。たとえば、現在のArchLinuxシステムで実行されている場合、その存在に依存するすべてのスクリプトが中断されます。したがって、スクリプトを実行しているコンピュータにどのツールのバージョンがあるかを確認する必要があります。これは、小規模にautoconfを再作成するように感じます。
2番目の質問については、デスクトップに一種の「ユニバーサルアイデンティティ」を提供したいと思います。インストール後の構成スクリプトでは、これを達成するために次の行を使用します。
scp user@server:/export/admin/*.jpg /usr/share/backgrounds/
scp user@server:/export/admin/ubuntu-wallpapers.xml /usr/share/gnome-background-properties/
sed 's/warty-final-ubuntu\.png/MyBackground\.jpg/' -i /usr/share/gconf/defaults/10_libgnome2-common
sed 's/warty\-final\-ubuntu\.png/MyBackground\.jpg/' -i /usr/share/gconf/defaults/16_ubuntu-wallpapers
sed 's/ubuntu-mono-dark/ubuntu-mono-light/' -i /usr/share/gconf/defaults/16_ubuntu-artwork
sed 's/Ambiance/Clearlooks/' -i /usr/share/gconf/defaults/16_ubuntu-artwork
CIの作成は、組織管理者の共通の仕事だと思います。それでは、デスクトップ全体に中央構成ツールがないのはなぜですか？ 2つの異なる設定ファイルに2つの（同じ！）文書化されていない値を設定する必要があることは奇妙に感じます。
質問
組織環境で複数のクライアントにわたって集中型統合構成をどのように処理しますか？
DebianのFAIのようなシステムが「最初にインストールして後でスクリプトを実行する」アプローチに比べて（CDを変更する必要がないことに加えて）どのような重要な利点がありますか？
ディストリビューションのメジャーバージョン間変換のベストプラクティスは何ですか？そして、技術的な問題を超えてユーザーエクスペリエンスの観点から長期的な安定性を保証するデスクトップ環境はありますか？私のユーザーをKDE 4またはGNOME 3に移行できないようですが、XFCEにはまだいくつかの機能障害があります...
この種の構成問題を解決できる*nixシステムはありますか？たとえば、組織の一部の画像（ロゴ、背景画像、色、フォントセットなど）を提供し、それをログインマネージャ、ユーザーデスクトップ、Webアプリケーション（！）などに適用するように要求するシステムがあるとします。 。注：私たちの場合は、シッククライアントで作業する必要があるため、純粋なシンクライアントソリューションは役に立ちません。
答え1
使用人形CFEngineまたはChefのいずれかがあなたの問題に適したソリューションです。もちろん、正しく機能するPuppetスクリプトを書くには時間がかかり、試行錯誤を受ける必要があります。これらのツールは、クラウドでの複雑なインストールを自動化し、私たちのような管理者の生活を簡素化するために広く使用されています。 :)
答え2
まず、複数のディストリビューションを使用するのは簡単だとは思わないでください。
まだ大規模なデスクトップ展開を行っていません。私にとって最良の妥協点は、LAN boot / tftpを使用してシステムを起動し、NFSを介してインストールを実行することです。ほとんどのLinuxディストリビューションは、すべての初期設定を事前に実行するように要求します。その後、インストーラに「本当にこのプログラムを実行しますか？」というメッセージなしで40分間無人で実行させることができます。当時、私はRedhatとSuseシステムを管理していましたが、標準インストールが完了した後にインストールしたすべてのカスタム設定を含むRPMを準備しました。しかし、それは非常に可能ですこれらすべてを自動化さまざまなディストリビューションについて
私はいろいろな理由でUbuntuディストリビューションの熱心なファンではありませんが、Canonicalのディストリビューションは風景とても印象的なツールです。大規模なUbuntuインストールの多くを実行したり、複数のUbuntuデスクトップを管理したりする場合は、詳しく調べる価値があります。
答え3
私は'というソフトウェアを使って多くのことをしてきました。CFエンジン。これは、ユーザーが設定した「ルール」を読み、バインドされているすべてのコンピュータがそのルールに準拠していることを確認するオープンソース構成マネージャです。完全オープンソース非常に役に立ったので、私たちの会社はサポートされているNovaというソフトウェアバージョンを使用することにしました。
これは、それがどのように機能するかについての広範な見解です。ホスティングネットワークに4台のコンピュータがあるとしましょう。彼らはすべてrootが所有するファイルを持っている必要があります/etc/syslog.conf（専門家によると）、chmod 777CFEngineの設定ファイルでこのルールを作成できます。/etc/syslog.conf中央コンピュータから「マスター」ファイルをインポートできます。 X時間ごとに、コンピュータのCFEngineバージョンは、ネットワークを介して各ボックスに/etc/syslog.confファイルを要求します。各クライアントで実行されているCFEngineのローカルコピーは関連ファイルを照会し、そのファイルの内容、権限などを報告します。キャスター・コピーと正確に一致しない場合、CFEngine はコピーをクライアントにプッシュし、ファイルを再確認します。彼らは一致し、彼はあなたの次の規則に進みます。
簡単にするために、CFEngineの「ルール」（Promiseと呼ばれる）で使用される構文は、慣れるのに少し時間がかかるかもしれませんが、学ぶ価値が十分にあります（そして技術セットに別の優れた技術を追加することができます）。
答え4
それでは、なぜ中央設定ツールがないのでしょうか？
Gnomeには、これらすべての小さなタスクを実行するGConfがあります。
http://wiki.novell.com/index.php/Locking_Down_the_GNOME_Desktop
http://library.gnome.org/admin/system-admin-guide/stable/gconf-9.html.en
Ubuntu LTSは、デスクトップでの長期サポートのためのほとんど唯一のオプションです。
単一の簡単な展開で複数のコンピュータを展開することはほとんど可能であり、ddデスクトップの展開により、これらの魅力が徐々に減少しています。
今、考慮すべき別のオプションがあります。脂肪質の顧客。