Unixoid 데스크톱 배포를위한 모범 사례와 향후 계획은 무엇입니까? [닫은]

비영리 무선 관측소를 위해 Linux 데스크톱을 설정했습니다. 저에게는 처음으로 로그인, 홈 디렉토리 등을 중앙 집중화하는 여러 동일한 시스템을 "배포"하는 것에 대해 생각해야했습니다. 아마도 직관과는 달리, "모든 것이 텍스트"라는 철학이 반드시 쉬운 일이되는 것은 아니라는 사실을 알게되었습니다.

필자의 경우 각 컴퓨터에 Ubuntu 10.04 LTS를 설치하고있었습니다. 설치 후 구성 파일을 변경하고 소프트웨어를 제거 및 설치하며 배경 이미지 또는 브라우저 책갈피와 같은 일부 파일을 서버에서 복사하는 사용자 지정 스크립트를 실행했습니다. 그러나 내 질문은 배포와 무관하다고 생각합니다.

문제

주로 두 가지 문제가 발생했습니다. 첫째, 배포 및 버전간에 일관성이없는 도구와 구성 파일, 두 번째 문제는 쉽고 직관적 인 방식으로 구성 파일에 설정을 노출시키지 않는 중요한 소프트웨어입니다.

내가 의미하는 바에 대한 두 가지 간단한 예를 들어 보겠습니다.

ifconfig도구에 의해 대체되고있다 ip. 예를 들어 현재 ArchLinux 상자에서 실행하는 경우 전자의 존재에 의존하는 모든 스크립트가 작동하지 않습니다. 따라서 스크립트를 실행하는 컴퓨터에 어떤 버전의 도구가 있는지 확인해야합니다. 어떻게하면 autoconf를 소규모로 다시 만드는 것처럼 느껴집니다.

두 번째 문제는 데스크탑에 일종의 "공통 동일성"을 부여하고 싶다고 생각하십시오. 설치 후 구성 스크립트에서 다음 줄을 사용하여이를 수행합니다.

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를 만드는 것이 조직 관리자에게는 일반적인 작업이라고 생각합니다. 그렇다면 중앙 구성 기능이없고 심지어 데스크탑 간이 없을까요? 두 개의 서로 다른 구성 파일에 두 개의 (동일한!) 문서화되지 않은 값을 설정해야한다는 사실이 이상합니다.

질문

조직 환경에서 여러 클라이언트의 중앙 통합 구성을 어떻게 처리합니까?

데비안의 FAI와 같은 시스템은 "먼저 설치 후 스크립트 실행"방법에 비해 CD를 변경할 필요가없는 것 외에 상당한 이점을 제공합니까?

배포판의 주요 버전 간 전환에 대한 모범 사례는 무엇입니까? 기술적 인 측면을 제외하고 : 사용자 환경과 관련하여 장기적인 안정성을 보장하는 데스크탑 환경이 있습니까? 사용자를 KDE 4 또는 그놈 3으로 마이그레이션 할 수는 없지만 XFCE에는 여전히 몇 가지 기능적인 단점이 있습니다 ...

이러한 유형의 구성 문제를 해결하는 * nix 시스템이 있습니까? 예를 들어, 조직의 이미지 (로고, 배경 이미지, 색상 및 글꼴 세트 등)를 요청하고 로그인 관리자, 사용자 데스크탑, 웹 응용 프로그램 (!) 등에 적용하는 시스템이 있다고 가정합니다. 의 위에. 참고 : 우리의 경우, 뚱뚱한 고객과 일해야하므로 순수한 씬 클라이언트 솔루션이 도움이되지 않습니다.

사용 인형 이나 cfengine이 나 요리사 당신의 문제에 적합한 솔루션이다. 물론 작동하는 Puppet 스크립트를 작성하는 데 약간의 시간과 시행 착오 접근법이 필요합니다. 이 도구는 클라우드에서 복잡한 설치를 자동화하는 데 널리 사용되며 우리와 같은 관리자의 삶을 단순화했습니다. :)

우선, 이것이 여러 배포판으로 쉽게 작업 할 것이라고 기대하지 마십시오.

큰 데스크톱 롤아웃을 실행하지 않았습니다. 저에게 가장 좋은 방법은 LAN 부트 / tftp를 사용하여 시스템을 부트 스트랩 한 다음 NFS를 통한 설치를 실행하는 것이 었습니다. 대부분의 Linux 배포판은 초기 설정을 모두 요구합니다. 그런 다음 설치 프로그램을 무인 상태로 40 분 동안 그대로 둘 수 있습니다 ( "이 프로그램을 정말로 실행 하시겠습니까?"프롬프트가 표시되지 않음). 그 시점에서 나는 Redhat과 Suse 머신을 살펴 보았습니다. 표준 설치가 완료된 후 설치 한 모든 커스텀 설정을 RPM에 준비했습니다. 그러나 다양한 배포판 에서이 모든 것을 자동화하는 것이 가능합니다 .

나는 여러 가지 이유로 우분투 배포판을 좋아하지 않지만 Canonical의 Lanscape 는 매우 인상적인 도구입니다. 그리고 대규모 Ubuntu를 여러 대의 Ubuntu 설치 / 관리하려면 여러 가지 Ubuntu 데스크탑을 설치해야합니다.

CFEngine 이라는 소프트웨어로 많은 작업을 해왔습니다 . 사용자가 설정 한 "규칙"을 읽고 해당 시스템에 연결된 모든 시스템이 해당 규칙을 준수하는지 확인하는 오픈 소스 구성 관리자입니다. 그것은 완전히 오픈 소스 이므로 우리 회사는 Nova라는 지원되는 버전의 소프트웨어를 사용하기로 결정했습니다.

이것은 작동 방식에 대한 광범위한 견해입니다. 관리 네트워크에 4 대의 컴퓨터가 있다고 가정 해 봅시다. 그들 모두는 /etc/syslog.conf루트가 소유 한 파일을 가져야하며 모두 동일하다 (마스터에 따라) chmod 777. CFEngine의 구성 파일에서이 규칙을 작성합니다. 중앙 컴퓨터에는 "마스터" /etc/syslog.conf파일이 있습니다. 매 X 시간마다 컴퓨터의 CFEngine 버전은 네트워크를 통해 각 상자에 /etc/syslog.conf파일 에 대해 묻습니다 . 각 클라이언트에서 실행중인 CFEngine의 로컬 사본은 해당 파일을 조회하고 파일의 내용, 권한 등을 다시보고합니다. 캐스터 사본과 정확하게 일치하지 않으면 CFEngine은 사본을 클라이언트에 푸시하고 파일을 다시 확인합니다. 그들은 일치하고 다음 규칙으로 넘어갑니다.

간단하게 말하면 CFEngine의 "규칙"(약속이라고 함)에 사용 된 구문에 익숙해지는 데 약간의 시간이 걸릴 수 있지만 학습 가치가 있습니다 (스킬 셋에 또 다른 훌륭한 기술을 추가 함).

중앙 설정 기능이없는 이유는 무엇입니까?

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배포 만으로도 여러 대의 컴퓨터를 배포 할 수 있으며 데스크톱 배포가 서서히 매력적인 경로가 아닙니다.

또한 옵션은 소위 fat client 입니다.