Webtagr - 기술 뉴스 다이제스트

인기 태그：

가상화 DNS 보안 형식적 검증 도달 가능성 분석 C언어 경제 컴파일러 오류 매크로 충돌 웹 확장 기능 개발 프레임워크 모든 태그

systemd 서비스 유닛 제한: 데몬 시작 실패의 일반적인 원인

2025-09-20

Linux 시스템 관리자에게 흔히 발생하는 문제 중 하나는 데몬이 일반적인 시스템 구성에서는 시작되지 않지만, root 권한으로 수동으로 실행하면 정상적으로 작동하는 경우입니다. 전통적인 원인으로는 환경 변수 $PATH 설정이 불완전하거나, SELinux, AppArmor 등이 있습니다. 최근에는 systemd 서비스 유닛 제한(systemd.exec에 설명됨)이 원인인 경우가 증가하고 있습니다. ProtectHome이나 PrivateTmp 같은 지시어로 인해 '권한 거부' 또는 '파일을 찾을 수 없음'과 같은 알 수 없는 오류가 발생하거나, DNS 쿼리가 차단되는 등 간접적인 오류가 발생할 수 있습니다. 데몬의 .service 파일에서 제한을 제거하면 문제 진단에 도움이 되지만, 미래의 데몬은 이러한 제한에 의존할 가능성이 있어 문제 해결이 복잡해질 수 있습니다.

(utcc.utoronto.ca)

개발 데몬

간과되고 있는 클라이언트 사이드 웹 경험: 느린 로딩 시간을 아무도 신경 쓰지 않는 이유

2025-08-23

이 글에서는 종종 간과되는 클라이언트 사이드 웹 경험의 문제점을 논의합니다. 서버 사이드 문제는 자주 논의의 대상이 되지만, 저자는 느린 로딩 시간, 불편한 UI, 기타 클라이언트 사이드의 불만이 지속적으로 무시되고 있다는 점을 지적합니다. Github의 최근 업데이트를 예로 들어 많은 사용자가 성능 저하를 보고하고 있음에도 불구하고, 웹사이트 운영자는 서버 사이드 문제를 우선시합니다. 저자는 웹사이트가 상당한 권한을 가지고 있으며, 사용자는 보이콧 외에는 방법이 없지만, 그 효과는 거의 없다고 주장합니다. 웹사이트는 종종 사용자 이탈을 효과적으로 측정하지 못하여 클라이언트 사이드 경험에 대한 무관심으로 이어집니다. 마지막으로 저자는 사용자에게 부정적인 영향을 미칠 수 있는 편집상의 결정을 내렸다는 것을 인정하지만, 이는 필요한 타협이라고 생각합니다.

(utcc.utoronto.ca)

개발 클라이언트 사이드

Linux에서 OpenBSD의 pflog 기능 재현하기: nftables와 ulogd2

2025-08-16

이 문서는 Linux 시스템에서 nftables와 ulogd2를 사용하여 OpenBSD와 FreeBSD의 편리한 pflog 기능을 재현하는 방법을 설명합니다. nftables 규칙에 'log group' 문을 추가하고 로그 정보를 다른 netlink 소켓으로 전달하여 tcpdump로 실시간 모니터링을 하고 ulogd2로 디스크에 로그를 기록할 수 있습니다. 이 문서에서는 ulogd2 구성, pcap 파일로 로깅, ulogd2의 제한 사항과 대안에 대해 자세히 설명합니다.

(utcc.utoronto.ca)

개발

기존 Unix 로그인 서버의 예상치 못한 지속성

2025-08-03

저자는 최신 그린필드 개발로 컴퓨팅 환경을 가상적으로 재구축할 때 기존 Unix 로그인 서버가 놀라울 정도로 지속적으로 사용되고 있다는 점을 탐구합니다. 컨테이너화가 보편화되었음에도 불구하고, CPU와 RAM 제한이 있는 범용 서버와 무제한 리소스 액세스를 제공하는 컴퓨팅 서버의 두 가지 유형이 유지됩니다. 사용률은 감소했지만, 이러한 서버는 특히 내부 머신에 대한 SSH 연결이나 VSCode와 같은 개발 환경의 백엔드를 실행하는 경우 놀랍도록 관련성을 유지합니다. 또한 cron 작업에서 로그인 서버의 사용과 사용자가 파일 서버에 코드를 저장하는 이유(SLURM 클러스터 및 컴퓨팅 서버 사용과 밀접하게 관련됨)에 대해서도 언급합니다. 견고한 지원 모델이 없기 때문에 정확한 사용 현황을 추적하기 어렵습니다.

(utcc.utoronto.ca)

개발 Unix 서버

재귀 하강 파서: 단순함이 복잡성을 능가하는가?

2025-07-28

저자는 컴퓨터 언어 파싱 접근 방식, 특히 재귀 하강 파서와 LR 파서 생성기를 비교 분석합니다. LR 파서 생성기는 더 복잡한 문법을 처리할 수 있지만, 저자는 재귀 하강 파서가 사용하기 쉽고, 외부 도구에 의존하지 않으며, 대상 언어로 직접 작성할 수 있으므로 학습 곡선과 디버깅의 어려움을 줄일 수 있다는 점을 강조합니다. 작은 언어의 파서를 만들어야 하는 개발자에게는 재귀 하강 파서의 단순성과 편의성이 복잡한 문법 처리의 한계를 능가하는 장점이 됩니다.

(utcc.utoronto.ca)

개발 재귀 하강

Bash 스크립트 디버깅: `set -e` 오류의 우아한 처리

2025-07-27

이 글에서는 Bash 스크립트에서 `set -e`로 인해 발생하는 오류를 우아하게 처리하는 방법을 소개합니다. `trap 'echo "Exit status $? at line $LINENO from: $BASH_COMMAND"' ERR`을 사용하면 스크립트에서 오류가 발생했을 때 오류 줄 번호, 실패한 명령어, 종료 상태 등의 정보를 출력하여 디버깅을 용이하게 합니다. 이는 Bash 고유의 `$LINENO`, `$BASH_COMMAND` 환경 변수와 `ERR` 트랩 조건을 활용합니다. sh와 같은 다른 셸에서는 동작이 다를 수 있으며, 이 기능을 완벽하게 지원하지 않을 수 있습니다.

(utcc.utoronto.ca)

개발 스크립트 디버깅

Linux errno(3)의 이상한 제한

2025-07-04

Linux의 errno(3) 매뉴얼 페이지는 이상한 제한을 보여줍니다. 함수 호출이 성공하더라도 errno가 변경될 수 있으며, 시스템 콜이나 라이브러리 함수가 errno를 0으로 설정하는 경우는 없습니다. 이는 Unix의 전통적인 설계 때문입니다. 시스템 콜은 일반적으로 실패할 때만 errno를 반환하고, 성공했을 때는 errno를 변경하지 않습니다. C 라이브러리 함수는 여러 시스템 콜을 수행할 수 있으며, 일부가 실패하더라도 라이브러리 함수 자체의 성공에는 영향을 미치지 않으므로 errno는 실패 값으로 남아 있을 수 있습니다. ANSI C와 POSIX는 이 동작을 상속했으며, 함수가 실패하고 해당 문서에서 errno 설정을 지정한 경우에만 errno가 의미를 갖도록 요구합니다.

(utcc.utoronto.ca)

개발

X 터미널의 예상치 못한 부상: X의 초기 설계에는 포함되지 않았던

2025-06-23

X는 처음에 X 터미널과 함께 사용하도록 설계되지 않았습니다. 초기 X는 완벽한 워크스테이션에서 실행되었습니다. 디스크리스 워크스테이션조차도 무거운 작업에는 서버에 의존했지만 여전히 완벽한 로컬 Unix 환경을 갖추고 있었습니다. X 터미널은 훨씬 나중에 등장했는데, X가 크로스벤더 Unix 윈도우 시스템으로 성공한 후였습니다. X 터미널을 처음 제작한 회사 중 하나인 NCD는 1987년에 설립되었지만, 제품 출시는 1989년까지 이루어지지 않았을 가능성이 높습니다. 이는 XDM(X 디스플레이 매니저)의 늦은 출시로도 뒷받침됩니다. XDM은 1988년 10월 X11R3과 함께 출시되었습니다. 기술적으로 XDM 없이 X 터미널을 사용하는 것은 가능했지만, XDM의 존재는 프로세스를 크게 단순화했습니다. 이는 X 터미널의 채택이 X 자체의 성숙에 뒤처져 있었음을 나타냅니다.

(utcc.utoronto.ca)

기술 X 윈도우 시스템 X 터미널

오픈소스 유지보수자 반란: libxml2 단독 유지보수자가 보안 문제를 더 이상 우선시하지 않음

2025-06-19

libxml2의 유일한 유지보수자가 보안 문제를 버그와 동일하게 처리하겠다고 발표하면서 오픈소스 커뮤니티에서 논쟁이 일고 있다. 저자는 이것이 오픈소스 소프트웨어의 기업 활용에 대한 유지보수자들의 불만이 커지고 있음을 반영한다고 주장한다. 개인적인 협력적인 오픈소스(예: Debian, BSD)와 이익을 위한 기업의 오픈소스 활용을 구분하고 있다. 저자는 앞으로 오픈소스 커뮤니티가 이러한 차이점을 더욱 강조하고 기업과의 상호작용이 변화할 것이라고 예측한다.

(utcc.utoronto.ca)

개발

WireGuard: 1Gbps 네트워크 대역폭 포화 달성

2025-06-17

저자는 이전까지 암호화는 기가비트 이더넷에서도 네트워크 포화에 도달하기에는 너무 느리다고 생각했습니다. 그러나 최근 테스트에서 쉽게 구할 수 있는 서버(Xeon E-2226G)에서 실행되는 WireGuard가 특별한 조정 없이 1Gbps 네트워크를 쉽게 포화시키고 CPU 사용률도 낮다는 것을 알게 되었습니다. 이는 암호화 속도에 대한 저자의 가정에 도전하는 것이며, 많은 방법이 이론적으로 1Gbps 링크를 포화시킬 수 있음을 시사하며, 기존 VPN 서버의 성능 조정이 필요함을 강조합니다.

(utcc.utoronto.ca)

개발 네트워크 대역폭 암호화 성능

Argparse의 상호 배타적 그룹 중첩 제한: 답답한 수수께끼

2025-06-14

Python의 argparse 모듈은 명령줄 인수 처리를 위한 편리한 기능(상호 배타적 그룹 포함)을 제공하지만, 중첩에 관해서는 답답한 제한이 있습니다. 여러 시간 초과 설정을 가진 프로그램을 생각해 보세요. 사용자는 개별 시간 초과를 조정하거나 완전히 비활성화할 수 있습니다. argparse는 개별 시간 초과 옵션 그룹 내에 '시간 초과 없음' 옵션을 중첩하는 것을 지원하지 않습니다. 이로 인해 설정이 번거로워집니다. 일반 그룹 내에 상호 배타적 그룹을 중첩할 수는 있지만, 그 반대는 지원되지 않으며 공식 문서에서도 이 제한이 명시적으로 언급됩니다. 따라서 개발자는 특정 스위치가 사용되었는지 수동으로 확인해야 하며, 이로 인해 복잡성이 증가합니다.

(utcc.utoronto.ca)

개발

Unix의 inode 0: 잊혀진 구석

2025-06-02

이 글에서는 초기 Unix 시스템에서 inode 번호의 제한과 inode 0의 특수한 경우에 대해 탐구합니다. 저자는 POSIX 표준이 inode 0의 사용을 명시적으로 금지하지는 않지만, 실제로 많은 시스템과 프로그램이 0이 아닌 inode 번호에 의존할 수 있다는 것을 발견했습니다. inode 0을 사용하면 예기치 않은 동작이 발생할 수 있으며, 일부 프로그램에서는 '파일이 없습니다' 신호로 해석될 수 있습니다. 사용자 공간 파일 시스템을 사용하여 inode 0을 실험해 볼 수 있지만, 호환성 문제와 예측할 수 없는 결과가 있으므로 권장하지 않습니다.

(utcc.utoronto.ca)

개발

LLM 대응을 위한 JavaScript 기반 작업 증명의 군비 경쟁

2025-05-28

웹사이트는 공격적인 LLM과 웹 스크래퍼에 대응하기 위해 Xe Iaso의 Anubis와 같은 JavaScript 기반 작업 증명 시스템을 점점 더 많이 사용하고 있습니다. 그러나 LLM은 해킹된 기계를 이용하여 이러한 과제를 해결하기 위해 막대한 CPU 시간을 확보할 수 있습니다. 문제는 LLM이 적대적인 환경에서 작동하며, 진정한 작업 증명과 악의적인 JavaScript를 구분하기 어렵다는 것입니다. 이로 인해 LLM은 CPU 마이닝이나 기타 공격을 받을 수 있습니다. 작업 증명 시스템을 식별하려는 시도는 악의적인 행위자가 모방할 유인이 있기 때문에 LLM에게는 패배의 게임입니다. 이는 웹사이트와 LLM 간에 각각 리소스 사용을 최적화하고 동시에 자신의 이익을 보호하려는 군비 경쟁을 촉발합니다.

(utcc.utoronto.ca)

개발

유닉스 파일 이름 길이 제한의 변천

2025-05-25

초기 유닉스 버전은 놀라울 정도로 짧은 파일 이름 길이 제한을 가지고 있었다. 처음에는 단 8바이트였고, 나중에 14바이트로 증가했다. 이는 유닉스의 단순한 디렉토리 구조 설계와 관련이 있다. 이 글에서는 유닉스 V4 이전 버전의 디렉토리 구조를 자세히 살펴보고 파일 이름 길이 제한의 진화 이유와 16바이트 디렉토리 항목이 512바이트 디스크 블록에 더 적합한 이유를 설명한다. 또한 초기 유닉스의 inode 수 제한에 대해서도 언급하며, 이는 이전 시스템의 몇 가지 하드코딩된 제한을 반영한다.

(utcc.utoronto.ca)

개발 유닉스 역사

Unix 도구를 사용한 IPv6 주소 정렬의 위험성

2025-05-19

이 글에서는 'sort' 와 같은 표준 Unix 명령줄 도구를 사용하여 IPv6 주소를 정렬하는 데 따르는 어려움에 대해 자세히 설명합니다. 복잡성은 IPv6의 16진수 표현, 선행 0의 부족 및 '::' 약어 표기법에서 비롯됩니다. 저자는 직접적인 해결책으로 IPv6 주소를 완전한 확장 형태로 변환하거나 Perl이나 Python과 같은 프로그래밍 언어를 사용하여 효율적인 정렬을 수행해야 한다고 주장합니다. 이는 기존 Unix 유틸리티가 IPv6 주소 형식의 뉘앙스를 직접 처리하는 데 적합하지 않기 때문입니다.

(utcc.utoronto.ca)

개발 정렬 Unix 명령줄

단일 프로세스 아키텍처: 현대적인 웹 개발을 위한 우아한 솔루션

2025-04-21

블로그 소프트웨어를 업데이트하는 동안 저자는 현대적인 웹의 복잡성을 처리하기 위해 CGI 기반 접근 방식보다 단일 프로세스 아키텍처가 더 간단하다는 것을 발견했습니다. 단일 프로세스는 공유 상태에 대한 쉬운 액세스를 허용하여 악의적인 트래픽 감지, 요청 속도 제한, 캐싱 구현과 같은 작업을 간소화합니다. 메모리 및 CPU 사용량은 우려 사항이지만, 구현의 용이성으로 인해 예측할 수 없는 것을 포함한 다양한 유형의 악용에 대처할 때 단일 프로세스 아키텍처가 유리합니다. 저자는 웹 악용이 증가함에 따라 단일 프로세스 아키텍처가 점점 더 중요해질 것이라고 생각합니다.

(utcc.utoronto.ca)

개발 단일 프로세스 아키텍처

ZFS 압축의 역설: 논리 블록 vs. 물리 블록

2025-04-17

압축이 활성화된 ZFS 파일 시스템에서 `dd` 명령어를 사용하여 만든 256KB 크기의 영(0) 파일이 이상한 동작을 보입니다. `ls -l` 명령어는 256KB로 표시하지만, `ls -s`와 `ls -slh` 명령어는 훨씬 작은 크기, 거의 0으로 표시합니다. 이는 ZFS의 효율적인 압축으로 인해 물리적 블록 수가 최소화되기 때문입니다. 이 글에서는 파일 크기를 측정하는 방법으로 논리적 크기(바이트), 물리적 블록 수, 논리적 블록 수의 세 가지 방법을 살펴보고, POSIX의 `st_blocks` 필드가 어떤 크기를 보고해야 하는지 명확하게 지정하지 않기 때문에 파일 시스템 간에 파일을 이동하면 `st_blocks` 값이 변경될 수 있으며, 경우에 따라 파일 크기가 늘어나 새로운 파일 시스템에 맞지 않을 수도 있음을 지적합니다.

(utcc.utoronto.ca)

개발

개인적인 Unix 패키지 관리 방식

2025-04-13

작성자는 Unix 시스템에서 개인 소프트웨어 패키지를 관리하는 영리한 방법을 공유합니다. 서로 다른 아키텍처의 소프트웨어를 `~/lib/` 디렉토리 트리에 저장하며, 각 프로그램은 별도의 버전이 지정된 하위 디렉토리(예: `emacs-30.1`)에 설치됩니다. `~/bin/bin.` 디렉토리에는 이러한 프로그램을 가리키는 심볼릭 링크 또는 래퍼 스크립트가 있어 버전 간 전환이 용이합니다. pipx나 Cargo와 같은 도구의 경우 기본 설치 위치를 유지하지만, 경로 충돌을 피하기 위해 `~/bin/bin.`에 링크를 생성합니다. 이 설정은 완벽하지 않지만 시스템 패키지 관리자를 통해 사용할 수 없거나 너무 오래된 소프트웨어를 관리하는 데 매우 유용합니다.

(utcc.utoronto.ca)

개발 소프트웨어 관리

Ubuntu 24.04에서 SSH 비밀번호 비활성화 버그

2025-04-06

Ubuntu 24.04 서버에서 인터넷을 통한 SSH 비밀번호 접근을 비활성화하고 로컬 LAN 접근은 허용하는 설정은 sshd_config를 사용하면 간단해 보입니다. 하지만 /etc/ssh/sshd_config.d/에 사용자 지정 설정 파일을 추가해도 SSH 데몬을 다시 시작한 후 설정이 무효화되는 문제가 발생했습니다. 원인은 sshd_config의 "선착순" 구성 규칙과 시스템에서 자동 생성된 50-cloud-init.conf 파일 내의 PasswordAuthentication yes 설정입니다. 이 파일이 먼저 로드되므로 사용자 지정 설정이 덮어쓰여집니다. 사용자 지정 설정 파일의 이름을 10-no-passwords.conf로 변경하여 먼저 로드되도록 하면 문제가 해결됩니다.

(utcc.utoronto.ca)

개발

광섬유 과다 프로비저닝: 예방이 최선의 치료

2025-03-25

방이나 건물 사이의 광섬유 케이블을 계획할 때는 처음에 필요한 양보다 더 많은 광섬유를 설치하는 것이 좋습니다. 미래 확장, 대역폭 업그레이드 및 새로운 프로토콜에는 추가 용량이 필요합니다. 또한 광섬유 고장이 발생하며(때로는 불가사의하게) 예비 쌍이 있으면 신속한 복구가 가능합니다. 단일 모드 광섬유와 멀티 모드 광섬유는 용도가 다르지만 충분한 중복성을 갖는 것이 가동 중지 시간과 비용을 최소화하는 데 필수적입니다.

(utcc.utoronto.ca)

하드웨어 광섬유 케이블 네트워크 인프라 중복성

Loki의 구조화된 메타데이터: 운영상의 악몽

2025-03-19

Grafana Loki는 종종 '로그를 위한 Prometheus'라고 불리지만, 초기에는 Prometheus와 유사한 데이터 모델을 채택했습니다. 그러나 이는 시스템 로그(syslog 또는 systemd journal)에 치명적인 결과를 초래했습니다. Prometheus와 달리 Loki는 각 레이블 값 집합을 별도로 저장하고 로그 저장소를 압축하지 않으므로 카디널리티 폭발이 발생합니다. 이를 해결하기 위해 Loki는 '구조화된 메타데이터'를 도입했지만, 3.0.0 버전 기준으로 아직 미완성 상태입니다. 구조화된 메타데이터 레이블은 일반적인 Loki 레이블로 취급되지 않으므로 다른 쿼리 구문이 필요합니다. 기존 레이블에서의 마이그레이션은 복잡하고 예기치 않은 고카디널리티 레이블 생성 위험이 있습니다. 업그레이드에는 주의가 필요하며, 기존 데이터 마이그레이션은 매우 비용이 많이 듭니다. 새로운 프로젝트에서 사용할 경우 이러한 제약 조건을 충분히 고려해야 합니다.

(utcc.utoronto.ca)

개발 시스템 로그

JSON: Unix 시스템에서의 기계 판독 가능 출력을 위한 실용적인 선택

2025-02-24

Postfix 메일 큐에서 이메일을 삭제한 경험을 바탕으로 저자는 기계 판독 가능 출력 형식으로 JSON을 사용할 것을 주장합니다. JSON은 완벽하지 않지만 Unix 시스템에서 명확성, 광범위한 호환성, 풍부한 도구 지원, 다른 형식으로의 쉬운 변환 등 여러 가지 실용적인 장점을 제공합니다. 저자는 새로운 프로그램의 경우 JSON만을 기계 판독 가능 출력 형식으로 사용하는 것이 가장 간단한 방법이며, 사용자 정의 형식 설계의 복잡성을 피하고 Unix 프로그램 간의 상호 운용성을 증진한다고 제안합니다.

(utcc.utoronto.ca)

개발 기계 판독 가능 출력

숨겨진 거대 캐시: 디스크 공간이 사라지는 이유

2025-02-08

많은 Unix 프로그램은 `.cache`나 `.local`과 같은 숨겨진 디렉토리에 데이터를 캐싱하는데, 이로 인해 사용자는 많은 디스크 공간을 차지하는 이러한 거대한 캐시 파일을 찾고 삭제하기 어렵습니다. 저자는 공유 파일 서버 환경에서 대학원생들이 이러한 숨겨진 캐시 때문에 혼란을 겪고 수백 GB의 디스크 공간이 자신도 모르게 소비되는 것을 목격했습니다. 이 글에서는 개발자들에게 캐시를 눈에 보이는 디렉토리에 저장하도록 촉구하고, 디스크 공간 사용 도구는 이러한 숨겨진 디렉토리의 콘텐츠를 명시적으로 표시해야 한다고 제안합니다.

(utcc.utoronto.ca)

개발 캐시 관리 디스크 공간 Unix 프로그램

VPN 접근을 악용한 정교한 피싱 공격

2025-01-29

토론토 대학교 컴퓨터 과학과는 매우 정교한 피싱 공격을 받았습니다. 공격자는 학과 이메일 주소를 위장하여 사용자의 비밀번호를 성공적으로 탈취했습니다. 놀랍게도 공격자는 훔친 자격 증명을 사용하여 짧은 시간 안에 학과 VPN에 등록한 후 내부 전용 SMTP 게이트웨이를 통해 스팸 메일을 발송했습니다. 이는 공격자가 사전에 표적의 VPN 및 이메일 환경을 충분히 조사했음을 보여주며, 점점 더 정교해지는 공격 기술과 강력한 사이버 보안 방어의 필요성을 강조합니다.

(utcc.utoronto.ca)

기술 VPN 악용

인터넷 연결 SSH의 암호 인증 비활성화: 보안 강화 또는 과잉?

2025-01-18

이 글에서는 인터넷에 연결된 SSH의 암호 인증을 비활성화하는 것의 장점과 단점을 비교 분석합니다. 강력한 암호는 브루트포스 공격으로부터 보호하지만, 저자는 암호 인증을 비활성화하면 도난당한 자격 증명, SSH 서버 취약점, 기본 계정을 노리는 공격 등에 대한 추가적인 보안 계층을 얻을 수 있다고 주장합니다. 하지만 이로 인해 키 페어 없이 로그인할 수 없는 등의 불편함이 발생할 수도 있습니다. 저자는 개별 상황에 따라 장단점을 신중하게 고려할 것을 제안합니다.

(utcc.utoronto.ca)

개발 SSH 보안 암호 인증

/etc/glob: 초기 Unix 쉘 글로빙의 숨겨진 이야기

2025-01-13

이 글은 초기 Unix 시스템에서 `/etc/glob`의 역사와 기능을 자세히 살펴봅니다. V7 Bourne Shell 이전에는 Unix 쉘의 와일드카드 확장(globbing)이 쉘 자체에서 처리되지 않고 외부 프로그램 `/etc/glob`에 위임되었습니다. `/etc/glob`는 명령어와 인수를 받아 와일드카드를 확장한 후 명령어를 실행했습니다. 이 글에서는 다양한 Unix 버전에서 `/etc/glob`의 작동 방식, 이스케이프 문자 처리, 외부 프로그램을 사용한 이유(초기 시스템의 리소스 제약 때문일 가능성이 높음) 등을 자세히 설명합니다.

(utcc.utoronto.ca)

개발 Unix 역사 쉘 글로빙

WireGuard 설정: 간단한 것부터 복잡한 것까지

2025-01-05

이 블로그 게시물에서는 완전히 격리된 내부 IP 주소 공간을 가진 가장 간단한 설정부터 WireGuard 터널 안팎에서 액세스할 수 있는 엔드포인트를 가진 가장 복잡한 "VPN" 설정까지 다양한 WireGuard 설정의 복잡성을 살펴봅니다. 저자는 라우팅 충돌 및 재귀적 라우팅과 같은 각 설정의 어려움과 잠재적인 문제점을 자세히 설명합니다. 이 기사에서는 사전 계획의 중요성을 강조하고 WireGuard 환경을 설계할 때 복잡한 라우팅을 피하기 위해 더 간단한 설정을 선택하는 것이 좋다고 제안합니다.

(utcc.utoronto.ca)

개발 네트워크 설정

Linux OpenZFS에서 zpool import/export의 잠재적 문제

2024-12-26

Linux OpenZFS(2.3.0 기준)에서 ZFS 풀의 임포트와 익스포트 관련 잠재적 문제가 있습니다. ZFS 풀에 'sharenfs' 속성이 설정된 파일 시스템이 없더라도 `zpool import`와 `zpool export`는 `exportfs -ra`를 실행합니다. 이로 인해 수동으로 추가하거나 수정한 NFS 익스포트가 삭제될 수 있으며, 사용자 지정 NFS 익스포트 설정을 사용하는 고가용성 시스템 등의 환경에 영향을 미칩니다. 이 문제는 OpenZFS가 NFS 익스포트 변경이 필요한지 여부와 관계없이 `exportfs -ra`를 무조건 실행하기 때문에 발생합니다.

(utcc.utoronto.ca)

개발

서버 재부팅 실패: 쿨다운 재부팅으로 커널 충돌 해결

2024-12-25

작성자는 단순 재부팅으로 해결할 수 없는 커널 충돌이 발생한 두 대의 동일한 서버를 발견했습니다. 충돌 시 서버는 시스템 펌웨어 단계에서 일련의 머신 체크 예외 오류를 출력하여 CPU 하드웨어 문제를 시사했습니다. 전원을 끄고 몇 분간 방치한 후 재부팅하여 문제를 해결했습니다. 이는 짧은 정전이라도 일부 x86 시스템 구성 요소가 완전히 재설정되지 않을 수 있으며 완전한 복구에는 쿨다운 시간이 필요함을 보여줍니다.

(utcc.utoronto.ca)

기술 서버 장애 커널 충돌 하드웨어 문제

10년 된 파일 서버의 제2의 삶: 비용 효율적인 스토리지 솔루션

2024-12-17

한 회사가 10년 이상 된 파일 서버를 운영 환경에서 여전히 사용하고 있습니다. 오래되었고 BMC가 KVM-over-IP에 Java를 필요로 하지만, 16개의 디스크 베이와 10G 이더넷 포트 덕분에 재활용에 적합합니다. 자체 디스크 방식의 저렴한 스토리지 서버로 사용되어, 오래되고 RAM이 제한적임에도 불구하고 대용량 저성능 스토리지 요구사항을 충족합니다. 이는 요구사항이 일치할 때 오래된 하드웨어의 재활용 가치를 보여줍니다.

(utcc.utoronto.ca)

기술 서버 재활용 스토리지 솔루션 하드웨어 비용

← Previous 1 2 Next →