Unixoidデスクトップの展開に関するベストプラクティスと今後の計画は何ですか? [閉鎖]

Unixoidデスクトップの展開に関するベストプラクティスと今後の計画は何ですか? [閉鎖]

私は非営利の伝播天文台のために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スクリプトを書くには時間がかかり、試行錯誤を受ける必要があります。これらのツールは、クラウドでの複雑なインストールを自動化し、私たちのような管理者の生活を簡素化するために広く使用されています。 :)

おすすめ記事