Unixoid 데스크탑 배포에 대한 모범 사례와 향후 계획은 무엇입니까? [폐쇄]

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 또는 GNOME 3으로 마이그레이션할 수 없을 것 같지만 XFCE에는 여전히 일부 기능 결함이 있습니다...

이런 종류의 구성 문제를 해결할 수 있는 *nix 시스템이 있습니까? 예를 들어, 조직의 일부 이미지(로고, 배경 이미지, 색상 및 글꼴 세트 등)를 제공하고 이를 로그인 관리자, 사용자 데스크탑, 웹 애플리케이션(!) 등에 적용하도록 요청하는 시스템이 있다고 가정합니다. . 참고: 우리의 경우에는 씩(thick) 클라이언트로 작업해야 하므로 순수한 씬 클라이언트 솔루션은 도움이 되지 않습니다.

답변1

사용인형CFEngine이나 Chef 중 하나가 귀하의 문제에 적합한 솔루션입니다. 물론 제대로 작동하는 Puppet 스크립트를 작성하려면 시간이 좀 걸리고 시행착오를 겪어야 합니다. 이러한 도구는 클라우드에서 복잡한 설치를 자동화하고 우리와 같은 관리자의 삶을 단순화하는 데 널리 사용됩니다. :)

답변2

첫째, 여러 배포판을 사용하는 것이 쉬울 것이라고 기대하지 마십시오.

아직 대규모 데스크톱 배포를 수행하지 않았습니다. 나에게 가장 좋은 절충안은 LAN boot/tftp를 사용하여 시스템을 부팅한 다음 NFS를 통해 설치를 실행하는 것입니다. 대부분의 Linux 배포판에서는 모든 초기 구성을 미리 수행하도록 요청합니다. 그런 다음 설치 프로그램이 "정말로 이 프로그램을 실행하시겠습니까?"라는 메시지 없이 40분 동안 무인 실행되도록 할 수 있습니다. 당시 저는 Redhat 및 Suse 시스템을 관리하고 있었고 표준 설치가 완료된 후 설치한 모든 사용자 정의 구성이 포함된 RPM을 준비했습니다. 그러나 그것은 매우 가능하다이 모든 것을 자동화하세요다양한 배포판에 대해

나는 여러 가지 이유로 우분투 배포판의 열렬한 팬은 아니지만 Canonical의 배포판은풍경매우 인상적인 도구입니다. 대규모 Ubuntu 설치를 많이 수행하거나 여러 Ubuntu 데스크탑을 관리하는 경우 자세히 살펴볼 가치가 있습니다.

답변3

저는 '라는 소프트웨어를 사용하여 많은 일을 해왔습니다.CF 엔진. 이는 사용자가 설정한 "규칙"을 읽고 바인딩된 모든 컴퓨터가 해당 규칙을 준수하는지 확인하는 오픈 소스 구성 관리자입니다. 완전히오픈 소스매우 유용했기 때문에 우리 회사는 지원되는 Nova라는 소프트웨어 버전을 사용하기로 결정했습니다.

이것은 그것이 어떻게 작동하는지에 대한 광범위한 견해입니다. 호스팅 네트워크에 4대의 컴퓨터가 있다고 가정해 보겠습니다. 그들은 모두 루트가 소유한 파일을 가지고 있어야 하며 /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데스크탑 배포로 인해 이러한 매력이 점차 줄어들고 있습니다.

이제 고려해야 할 또 다른 옵션이 있습니다.뚱뚱한 고객.

관련 정보