다른 사람들은 정방향 심볼릭 링크에 대해 어떻게 생각하는지 궁금합니다. 안전한가요? 좋은 연습? 의지하다? [편집] - 문제 공간에 너무 가까워서 용어가 잘 이해되지 않을 수 있으므로 정방향 심볼릭 링크를 정의하지 않았습니다.
루트와 /usr을 병합하려는 시도는 대부분 실패했기 때문에(bin, lib 및 lib64에 대한 두 개의 별도 디렉터리를 제거한 배포판(cygwin 제외, 배포판으로 간주하는 경우)은 알지 못합니다), 배포판에서는 주로 OpenSUSE를 사용합니다. 병합을 구현하는 방법은 /usr에 바이너리를 설치하는 것입니다. 많은 프로그램에는 많은 프로그램에 대한 경로가 하드 코딩되어 있으므로(/bin/이 아마도 가장 일반적임) 설치 패키지는 /bin/prog -> /usr/bin/prog에서 심볼릭 링크를 배치합니다. 이것만으로는 순방향 링크가 아닙니다(이 용어는 상위 디렉터리에서 하위 트리로의 감독자로 정의될 수 있지만 이는 분명히 많은 환경에서 문제가 되지 않습니다.
보안과 신뢰성이 관련된 환경에서는 1) 백업 및 복구 시간과 백업 공간을 최적화하기 위해 서로 다른 트리를 서로 다른 장치에 배치합니다. 2) 지워지거나 손상된 파티션 관련 문제가 포함되어 있습니다. 3) 공격에서 하드 링크 파일 및 기타 메커니즘의 사용을 허용할 수 있는 특정 보안 공격을 비활성화합니다. 이유 1과 관련하여 특정 디렉터리 및 하위 디렉터리에는 종종 작은 변경(/var)이 많이 발생합니다. 일부는 자주 변경되지 않습니다(/etc, /bin, /sbin). 일부는 매일 변경될 수 있습니다(/home). 유사하게 사용되는 디렉터리를 하나의 파티션으로 그룹화하면 자주 변경되지 않는 파티션의 백업이 줄어들 수 있으며, 자주 변경되는 디렉터리는 RAM 디스크나 SSD에 배치하는 것이 적합할 수 있습니다.
그러나 파티션이 다른 이유는 순방향 연결 방식이 안전한지 또는 "모범 사례"인지(또는 그렇지 않은지) 여부와는 아무런 관련이 없습니다. 좀 더 명확하게 설명하자면 /usr/{{s,}bin,lib64} 아래의 디렉터리를 가리키는 /bin, /sbin 및 /lib64에 심볼릭 링크를 배치합니다. "/usr"이 별도의 파티션인 경우 /{{에 링크를 지정합니다. s,}bin,lib64/는 "안전하지 않으며" 실제로 나쁜 관리 관행입니다. /usr을 보유하는 디스크가 아무리 안정적이더라도 어떤 이유로 마운트할 수 없는 경우 - 라이브러리는 바이너리 루트 디렉터리 /{에 링크되어 있습니다. bin,sbin,lib64}는가치 없는시스템이 시작되지 않게 됩니다.
저는 개인적으로 세 가지 상황을 경험했습니다. "마운트" 바이너리는 /usr/bin/mount에 있고, 심볼릭 링크는 /bin/mount에 있고, 최신 설치 프로그램은 여러 라이브러리로 재구성되었으며, /lib64 라이브러리의 심볼릭 링크는 /usr을 가리킵니다. 아직 설치되지 않은 /lib64 및 최근 실패 모드: 프로그램이 잘못된 번호의 lib 버전을 로드하는 것을 방지하기 위해 라이브러리 버전 번호를 바이너리 및 라이브러리에 넣습니다.
일반적으로 이 조합이 작동합니다. 주요 문제는 설치될 때까지 동반 디렉토리에 포함된 버전 번호를 모른다는 것입니다. 정상적인 작업 중에 루트 디렉터리의 파일은 /usr/lib64의 파일과 동적으로 링크될 수 있습니다. /usr이 마운트되지 않은 경우 /lib64에 있는 동일한 이름의 라이브러리와 연결을 시도하고 실패할 수 있습니다. 마지막 사례는 동일한 이름의 라이브러리를 /usr/lib64에서 /lib64로 복사하여 루트 파티션의 /usr에 대한 기호 링크를 실행 취소하려고 시도한 부작용입니다. 안타깝게도 동일한 패키지의 새 버전으로 업데이트할 때 새 버전이 루트 디렉터리에 복사되지 않습니다. /usr/lib64 복사본의 시간/날짜 스탬프가 /lib64의 시간/날짜 스탬프보다 오래된 경우 이를 캡처할 수 있는 쉬운 방법이 없습니다.
링커 유틸리티 'ldd'는 파일 이름 기반 버전이 있는 필수 라이브러리를 표시하지만 포함된 버전에 대해서는 즉시 알지 못합니다. 이 모든 추가 작업은 아직 마운트되지 않은 파일 시스템에 다른 파일 시스템을 마운트하고 부팅하는 데 필요한 리소스를 배치함으로써 발생합니다.
나는 아무도 이것을 나쁜 관행이라고 지적하지 않는 이유 중 하나가 누구도 그렇게 쉽게 실패할 수 있는 것을 구현할 것이라고 믿지 않았거나 새로 만들어진 이유가 "버그"가 아니라고 믿었기 때문이라고 강하게 생각합니다. " - 하드 디스크에서 직접 빠른 부팅이 더 이상 지원되지 않는 것처럼(원래 SuSE 설치 프로그램의 이전 버전에서 설정한) 분할 분할은 더 이상 지원되지 않습니다(시스템 개발자는 더 빠른 부팅 시간을 권장하지만).
불행하게도 새로운 데스크톱 개발자는 /usr/bin 파일을 /bin에 더 안전하게 병합하지 않고 이전 관리 방식을 무시하고 있습니다. 일부 이유는 루트에 충분한 공간이 없을 수 있기 때문입니다!
cygwin처럼 병합하지 않을 이유를 찾을 수 없습니다. (단지 /bin @ /usr/bin을 마운트합니다. 심볼릭 링크는 포함되지 않습니다.) 대신에 논쟁을 멈추고 그냥 받아들이라는 말을 들었습니다. 이는 다른 문제가 있는 행동/사건을 "수용"하라는 다소 가학적인 조언과 매우 흡사합니다.
마지막 마무리 문장: "제가 너무 보수적인 것인가요? 아니면 이제 정방향 링크가 중요한 문서의 '모범 사례' 영역에 있는 것으로 간주됩니까?"
새로운 실패 방식이 등장함에 따라 나는 이 문제에 대해 지나치게 보수적일 가능성을 더 이상 고려하지 않습니다. 나는 이것이 관리적인 "모범 사례"로 간주될 수 있는 방법이 없다고 생각합니다.
답변1
주어진 바이너리가 어디에 있어야 하는지( / 또는 /usr ) 알아내는 것은 불필요하게 복잡하고 아무런 목적도 없다는 주장이 있습니다. 시스템은 한동안 /usr 없이 부팅할 수 없었으므로 더 이상 두 디렉토리를 모두 유지할 이유가 없습니다.
바라보다http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge자세한 내용은.
답변2
심볼릭 링크를 광범위하게 (그리고 주의해서) 사용하는 더 좋은 이유는...
심볼릭 링크는 파일 시스템(계층적 데이터베이스)에 대한 것이고, 외래 키는 관계형 데이터베이스에 대한 것입니다.
"앞으로" 및 "뒤로" 심볼릭 링크를 신중하게 사용하면(이전에 이런 식으로 언급된 적이 없지만) /etc, /bin, /lib 및 /sbin이 있는 배포판을 설계하는 것이 가능합니다. 내용은 /usr/etc, /usr/bin, /usr/lib 및 /usr/sbin에 대한 심볼릭 링크입니다. /usr 디렉토리의 여러 버전은 /initrd(램디스크 초기화)와 같은 어딘가에 설치될 수 있습니다. 그런 다음 파일 시스템은 심볼릭 링크를 신중하게 생성하고 삭제하여 주어진 시간에 사용 중인 각 파일의 버전을 관리할 수 있습니다.
강아지리눅스다른 배포판과 함께 사용됨동맹그리고오브파일 시스템은 이 개념의 변형을 구현합니다.
분산 원본 운영 체제는 영구 저장소의 "기본 계층"으로 정적(변경되지 않음)으로 유지됩니다. 이러한 파일(예: /etc/hosts) 중 하나를 편집하고 저장하면 파일 시스템은 원본 파일을 변경하지 않고 램디스크의 최상위 "작업 계층"에 새 복사본을 생성합니다. 그러면 파일 시스템은 원본 대신 이 복사본을 사용자에게 제공합니다.
램디스크 복사본은 백그라운드에서 역시 영구 저장소에 있는 세 번째 계층으로 정기적으로(루트 사용자 구성 가능) 플러시됩니다. 변경 시 램디스크 복사본은 저장된 버전을 효과적으로 덮어쓰며, 결과적으로 정적 원본을 덮어씁니다. 최상위 복사본만 표시되므로(변경되지 않은 파일의 경우 원본 파일이 됨) 파일 시스템은 사용자와 다른 소프트웨어에게 완전히 일반적으로 보입니다.
이 기술은 시스템 속도와 안정성을 향상시킵니다.
- 사용자 시작 파일 읽기 및 쓰기는 항상 램디스크를 사용하기 때문에 매우 빠릅니다.
- 램디스크 계층에는 최근에 변경된 파일만 포함되므로 크기가 작고 다른 계층과 유사하게 작동합니다.은닉처.
- 느린 영구 저장소로의 플러시는 백그라운드 처리로 연기됩니다.
- "파일 저장"의 세 번째 계층 복사본은 주기적으로 만들어질 수 있으며, 구성 또는 설치 오류가 발생하거나 악성 프로그램이 감지된 경우 "실행 취소" 기능을 제공합니다.
심볼릭 링크가 이를 가능하게 합니다.
대답...
설정이 얼마나 "고속"입니까?
더 많은 메모리를 제공할수록 가상 디스크에 더 많은 프로그램을 저장할 수 있으므로 응답이 더 빨라집니다. 램디스크에서 프로그램을 시작하는 것은 플래시 메모리(플래시 드라이브, SD 등)에서 프로그램을 시작하는 것보다 약간 빠르며 하드 드라이브에서 동일한 프로그램을 시작하는 데 걸리는 시간의 일부만 소요됩니다.
64MB RAM을 갖춘 내 300MHz 1999 Toshiba 4030CDT 노트북에서 주로 Slackware를 기반으로 하는 Puppy Linux 5.2.2 Wary는 많은 램디스크를 위한 공간이 부족하여 프로그램이 하드 드라이브에서 로드됩니다. 그럼에도 불구하고 2D-GUI는 반응이 매우 좋습니다. Synergy를 통해 다른 모든 호스트에 연결하기 위해 "콘솔"로 사용합니다.
반면에 저는 현재 노트북을 통해 2.6GHz Celeron 프로세서와 1.3GB RAM을 실행하는 Compaq S6010V를 사용하고 있습니다. 램디스크 "PuppySpace"에는 512MB가 할당되어 있으며 그 중 현재 200MB 미만이 사용되고 있습니다. Zim(Python 메모 작성 애플리케이션), Geany 편집기/IDE, 5개 세션이 열려 있는 터미널 클라이언트, Chromium 사본 2개가 로드되어 Gmail을 포함하여 총 12개의 활성 웹 탭이 있습니다.
보통 얼마나 오래 켜져 있나요?
지속적으로 구성을 개발하고 변경하고 있으므로 예약된 재시작이 일반적입니다. Compaq의 가동 시간 출력은 현재...
16:21:10 up 4 days, 7:28, load average: 0.06, 0.24, 0.30
사용자가 kernel.org에서 자신의 커널을 쉽게 컴파일하고 부팅할 수 있습니까?
이건 해본 적이 없어서 알 수가 없네요. Puppy Linux 커뮤니티는 아침 식사로 자신의 커널을 컴파일하는 사람들로 가득 차 있습니다.
이것이 서버를 실행하는 것입니까?
내 모든 시스템은 JWM 또는 Openbox 창 관리자(GTK+ 기반)를 실행하지만 Puppy를 서버로 설정하는 작업을 일부 수행했습니다.렘프그리고단순화된 뮤직 서버 주크박스(mpdPup).
오르프스? …그것의 용도는 무엇입니까? (xfs/ext를 통해.
Aufs는 Unionfs를 완전히 재작성한 것입니다. 그들은 모두 그것을 달성했습니다공동 설치여러 파일 시스템(예: xfs, ext3/4 등)이 동일한 마운트 지점에 마운트되어 서로 덮어쓰는 경우.
답변3
지금은 /usr별도의 파티션을 만들지 않는 것이 좋습니다. 이렇게 하면 심볼릭 링크가 전혀 필요하지 않습니다.
적어도 그것은 내 배포판에서 바이너리 이동에 문제가 발생한 후에 결정한 것입니다. 모든 바이너리와 라이브러리를 동일한 파티션에 배치하는 것이 실제로 의미가 있습니다. 그러면 어느 것이 에 /bin있고 어느 것이 에 있는지는 중요하지 않으며 /usr/bin마음대로 이동할 수 있습니다.
/usr처음에 별도의 파티션을 만든 유일한 이유는 LVM을 사용하여 모든 파티션을 만들었기 때문입니다. 하지만 그 외에는 특별한 이유가 없습니다. 이별을 위한 이별.
모든 것에 대해 하나의 파티션이 있는 경우 루트 /파티션은 거의 완전히 비어 있습니다. 제 경우에는 200MB 미만이었습니다. 그래서 이를 /usr파티션과 병합하여 이전에 루트 파티션에서 쓸데없이 낭비되었던 공간을 확보했습니다. 아직까지는 단점을 찾지 못했습니다.
구조 시스템을 위한 병합 프로세스: (사용에 따른 책임은 본인에게 있습니다. 시스템이 손상될 수 있습니다.)
mkdir /mnt/root /mnt/usr
mount /dev/lvm/root /mnt/root
mount /dev/lvm/usr /mnt/usr
# /usr will be mounted as /, so move everything into a new usr/ subdirectory
mkdir /mnt/usr/usr
mv /mnt/usr/* /mnt/usr/usr/
# copy the root files, preserving hard links just in case
rsync -aH /mnt/root/. /mnt/usr/.
# update fstab: comment /usr, change UUID of / to the one of /usr
nano /mnt/usr/etc/fstab
umount /mnt/root
umount /mnt/usr
lvrename lvm/root lvm/oldroot
lvrename lvm/usr lvm/root
# chroot to see if it works and update grub UUID
mount /dev/lvm/root /mnt/root
mount -o bind /dev /mnt/root/dev
mount -o bind /proc /mnt/root/proc
mount -o bind /sys /mnt/root/sys
chroot /mnt/root /bin/bash
update-grub # may depend on distro/bootloader