기본 키/외래 키/고유/확인);
k) UTF-8 지원
l) 2상 잠금
m) 구문이 있는 SQL 편집기
대답:롤 후핀,
파이어 버드 - 첫사랑. Postgres - 아마도 편리한 결혼이 있을 것입니다.)))
질문: Postgres를 통해 디스크에 저장된 파일 검색
안녕 모두.
다음과 같은 간단한 작업이 있습니다. 사용자에게 다운로드하기 위해 브라우저에 파일을 반환하지만 문제는 파일이 디렉토리에 데이터베이스와 함께 서버에 저장되고 데이터베이스의 이름 ID(확장자 및 원래 이름), 원래 이름과 확장자는 데이터베이스의 별도 테이블에 저장됩니다.
이 파일은 postgres를 통해 다른 응용 프로그램에서 이 디렉토리로 로드되며 최소한 파일 확장자를 사용하여 내 응용 프로그램에서 파일을 받아야 합니다. 그래서 lo_import를 통해 이러한 파일을 가져오기로 결정하고 서버의 응용 프로그램에 대한 요청에서 반환한 다음 클라이언트로 반환하지만 여기에 문제가 있습니다. lo_import는 파일을 데이터베이스에 로드하고 oid를 반환합니다. 지금 이 데이터를 어떻게 얻을 수 있습니까? 실제로 로드 후 pg_largeobject로 끝났지만 파일이 (모든 부분을 결합하고 원하는 확장자를 추가한 후) 정상적으로 열리도록 조합할 수 없습니다. 수집을 시도했다
SELECT array_to_string(array(loid = 135422 페이지 번호별 주문인 pg_largeobject에서 데이터 선택),"");
대답:옵션 2
PG가 설치된 디스크의 모든 디렉토리에서 데이터를 가져올 수 있는 PlPerlU 확장을 설치한 후 Perl과 같은 언어로 고유한 저장 프로시저를 작성하십시오.
필요한 파일을 가져오는 함수의 예:
-- 기능: read_file_as_hex(텍스트)
드롭 기능 read_file_as_hex(텍스트);
CREATE OR REPLACE FUNCTION read_file_as_hex(이름 텍스트)
텍스트를 그대로 반환
$BODY$
내 $s = "";
내 $ 버프 = "";
내 $read_buff = "";
내 $file_name = $_;
내 $name_size = 길이($file_name);
$file_name = pack("H$name_size", $file_name);
(open(READING_FILE, $file_name)) (
리턴($버프);
) 또 다른 (
빈 모드(READING_FILE);
내 $file_size = -s($file_name);
읽기(READING_FILE, $read_buff, $file_size);
닫기(READING_FILE);
$s = 2*$파일_크기;
$buff = unpack("H$s", $read_buff);
리턴($버프);
}
$BODY$
언어 plperlu 휘발성
비용 100;
변경 기능 read_file_as_hex(텍스트)
소유자에게 postgres;
파일은 자바 브라우저(e)에서 HEX 시퀀스로 전송되어 그대로 어셈블됩니다.
질문: DBMS 오류, SQL 서버연결을 허용하지 않고 SQL 서버를 다시 시작하는 것만으로도 도움이 됩니다.
서버 2008R2 + SQL 2012 + 서버 1C
도움 협의회, MSSQL을 사용하면 의사 소통이 그다지 필요하지 않았습니다. 결론은 1C 사용자가 한 번에 중단되고 DBMS 오류가 발생하여 다시 로그인할 수 없다는 것입니다. SQL Server 및 SQL Agent 서비스를 다시 시작합니다. 애플리케이션 로그에서: 세부 정보 2016-03-21 오전 10:03:58 MSSQL$MSSQL2012 17052 서버
소스 MSSQL$MSSQL2012에서 이벤트 ID 17052에 대한 설명을 찾을 수 없습니다. 이 이벤트를 발생시킨 구성 요소가 이 컴퓨터에 설치되어 있지 않습니다. 로컬 컴퓨터또는 손상됨. 로컬 컴퓨터에 구성 요소를 설치하거나 복구합니다.
이벤트가 다른 컴퓨터에서 시작된 경우 표시된 정보를 이벤트와 함께 저장해야 할 수 있습니다.
이벤트에 다음 정보가 추가되었습니다.
SQLServerAgent 모니터: SQLServerAgent가 닫혔습니다.
메시지 리소스가 있지만 문자열 테이블 및 메시지 테이블에서 메시지를 찾을 수 없습니다.
세부 정보 2016-03-21 오전 10:04:04 MSSQL$MSSQL2012 17144 서버
서비스 제어 관리자가 일시 중지를 요청했기 때문에 SQL Server에서 새 연결을 허용하지 않습니다. 서비스를 재개하려면 SQL Compute Manager 또는 제어판의 서비스 앱을 사용하십시오.
오류 2016-03-21 오전 10:04:09 MSSQL$MSSQL2012 17120 서버
SQL Server에서 증분 신호 스트림을 만들 수 없습니다. SQL Server 오류 로그 및 Windows 이벤트 로그를 검토하고 유사한 문제에 대한 정보를 찾으십시오.
세부 정보 2016-03-21 오전 10:04:09 MSSQL$MSSQL2012 19032 서버
서버 종료로 인해 SQL 추적이 중지되었습니다. 추적 ID = "1". 이것은 정보 메시지입니다. 사용자 개입이 필요하지 않습니다.
내가 이해하는 한 서버는 오류 17120을 입력하지만 발생 이유와 마찬가지로 의미에 대한 합리적인 설명을 찾을 수 없습니다.
SQL 로그인 첨부 파일입니다. 직접 읽어보려고 했으나 이해가 거의 되지 않았다. 나는 구루의 지혜에 호소한다!
첨부 파일 ( 매거진.rar- 17Kb)
대답: invm,
이 기간의 첫 번째 이벤트는 에이전트 로그의 항목입니다.
2016년 3월 21일 10시 3분 51초, 상세, 중지 요청 시 SQLAgent$MSSQL2012 서비스 중지 사용자로부터 받은 프로세스 또는 OS ...
그런 다음 타임라인에서 다른 모든 이벤트가 발생합니다. 이 요청을 보낸 사람을 추적하는 방법은 다음과 같습니다. 이 기간 동안 스케줄러에 작업이 없습니다. 백업은 모두 밤에 수행됩니다. 충돌에 앞서 로그에 반복되는 이벤트가 없습니다. 또한 충돌은 매일이 아니라 다른 시간에 발생합니다. 마지막 시간은 03/15/16입니다.
질문: OUT 매개변수로 Postgres 프로시저를 호출하는 방법
안녕하세요! 한 프로젝트의 경우 Postgres를 선택했습니다.
습관적으로, 나는 가장 간단한 것을 구현할 수 없습니다.
SQL Server에서 OUT 매개 변수가 있는 프로시저를 만들고 호출한 경우 외부 프로그램따라서 (2 OUT 매개변수 및 2 일반)
EXEC 절차? @중. 파1, ? @중. 파2, ? 중. 파3, ? 중. 파4
동시에, 절차 실행 후 내 변수 m.par1 및 m.par2는 해당 매개 변수의 값을 취했습니다.
내 관찰에 따르면 Postgres는 OUT 매개변수를 프로시저에 전달할 필요가 전혀 없습니다. 즉, 제 경우에는 두 개의 매개변수를 프로시저에 전달해야 하는 것 같습니다. 예, DBeaver에서는 4개가 아니라 2개의 매개변수로 표시됩니다(OUT 매개변수는 무시됨).
예를 들어 OUT 매개변수를 사용하여 새로운 고유 코드를 얻는 가장 간단한 절차와 같이 프로그램에서 생성하고 호출하는 방법을 알려주십시오. SQL 유형섬기는 사람
CREATE PROCEDURE dbo. new_id @nRetVal int 업데이트 시작으로 출력 id_counter SET @nRetVal = id_counter. 아이디, 아이디_카운터. 아이디 = 아이디_카운터. 아이디 + 1
EXECUTE 프로시저를 사용해야 합니다.
또는
구성을 선택<моя переменная>절차(매개변수)에서?
내 프로그램에서 변수를 전달해야 합니다. 원하는 유형, 그러나 임의의 이름을 사용하여 Postgres 프로시저에 넣고 이 프로시저를 실행한 후 변수는 프로시저의 해당 매개변수에 할당된 값을 취합니다.
37.4.1. SQL 함수 인수37.4.4. SQL 함수출력 매개변수 포함4.3.1. 위치 기어4.3.2. 공칭 전송4.3.3. 혼합 전송
VARCHAR(255)) "SC_Wonder"에서 이름으로. t_page T1 WHERE T1. p_parent IS NULL 유니온 선택 T2. p_id, T2. p_parent, T2. p_title, CAST ( temp1. PATH || "->" || T2. p_id AS VARCHAR (50)) , LEVEL + 1 , CAST ( " " || temp1. NAME AS VARCHAR (255)) FROM "SC_Wonder". t_page T2 INNER JOIN temp1 ON ( temp1.p_id= T2.p_parent)) select * from temp1 ORDER BY PATH LIMIT 100
그는 내놓는다
이름 필드에
_10
___10
등등. 여기서 1은 첫 번째 항목의 이름입니다.
현재 항목의 이름을 이기고 강제로 출력하는 방법
대답:정확히 무엇이 필요한지. 감사. 정말 내가 해냈어
CAST ( lpad ( "" , (LEVEL + 1)* 3, " " ) || T2. p_title AS VARCHAR (255))
질문: Oracle 설정 도움말 - Postgres DBLINK
여보세요.
oracle에서 postgres로 연결해야 합니다.
에 이 순간 oracle과 postgres가 내 로컬 컴퓨터에서 실행 중입니다. caths.sql 파일이 작성되어 설치되었습니다.
그런 다음 nsnames.ora에 입력
WMS= (설명= (주소=(프로토콜=tcp) (호스트=로컬호스트) (포트= 5432
)) (CONNECT_DATA = (SERVICE_NAME=지도)) (HS = OK))
그리고 DBLINK를 만들었습니다.
"WMS"를 사용하여 데이터베이스 링크 맵 생성
요청에 따라
에서 이름 선택 [이메일 보호됨]
오류가 발생합니다
오류 1
:오라- 28545
: 에이전트 연결 시 Net8에서 진단한 오류 NETWORK/NCR 메시지의 텍스트를 검색할 수 없습니다. 65535
오라- 02063
: 선행 2
MAP의 라인
내가 무엇을 잘못했고 연결을 설정하는 방법은 무엇입니까?
1C:Enterprise 및 PostgreSQL 서버 번들은 1C 설치 중 두 번째로 인기 있고 Linux 플랫폼에서 가장 많이 사용되는 솔루션입니다. 작동하지 않게 하기 어려운 Windows 및 MSSQL 기반 구현과 달리 Linux 기반 구현은 경험이 부족한 관리자에게 많은 함정이 있습니다. 모든 것이 올바르게 수행된 것처럼 보이지만 오류는 오류 뒤에 오는 경우가 많습니다. 오늘 우리는 그 중 가장 전형적인 것을 고려할 것입니다.
일반 정보
설치 오류를 찾기 시작하고 일반적으로 1C:Enterprise의 서버 버전 구현을 시작하기 전에 작동 방식에 대한 이해를 새롭게 하는 것이 좋습니다.
소규모 구현에서 1C 서버와 DBMS 서버는 일반적으로 동일한 서버에 결합됩니다. 물리적 서버, 이는 원을 약간 좁힙니다. 가능한 오류. 우리의 경우 서버가 다른 시스템으로 분리된 상황을 고려할 것입니다. 테스트 랩에서 다음 스키마를 배포했습니다.
처분할 수 있는 두 대의 서버가 있습니다. 우분투 실행 12.04 x64, 그 중 하나에는 1C:Enterprise 서버 버전 8.3이 설치되어 있고 다른 하나에는 Ethersoft의 PostgreSQL 9.04와 다음 클라이언트가 있습니다. 윈도우 컨트롤. 클라이언트가 작업 중임을 상기시킵니다. 뿐차례로 DBMS 서버에 필요한 쿼리를 생성하는 1C 서버와 함께. 클라이언트에서 데이터베이스 관리 서버로의 요청 없음 일어나지 않는.
중요: 사용자 "postgres"가 인증되지 않았습니다(Ident).
이 오류는 로컬 네트워크에서 잘못 구성된 인증으로 인해 서버가 다른 PC에 분산되어 있을 때 발생합니다. 수정하려면 엽니다. /var/lib/pgsql/data/pg_hba.conf, 다음 행을 찾습니다.
모든 192.168.31.0/24 ident 호스트
다음과 같이 보이게 합니다.
호스트 모두 192.168.31.0/24 md5
어디 192.168.31.0/24
- 로컬 네트워크의 범위. 해당 라인이 없는 경우 섹션에 생성해야 합니다. IPv4 로컬 연결.
데이터베이스 서버를 찾을 수 없습니다.
호스트 이름 "NAME"을 주소로 변환할 수 없음: 이름 확인의 일시적 실패
언뜻보기에 오류는 분명합니다. 클라이언트는 DBMS 서버의 이름을 확인할 수 없으며, 전형적인 실수없는 소규모 네트워크의 경우 로컬 DNS 서버. 솔루션으로 파일에 항목 추가 호스트어떤 결과도 제공하지 않는 클라이언트에서 ...
그리고 이제 우리는 조금 전에 말한 것을 기억합니다. DBMS 서버의 클라이언트는 1C 서버이지만 클라이언트 PC가 아니므로 파일에 1C: Enterprise 서버에 항목을 추가해야 합니다. /etc/hosts Linux 플랫폼 또는 Windows 플랫폼에서.
추가하는 것을 잊은 경우에도 유사한 오류가 발생합니다. 레코드 유형 A로컬 DNS 서버의 DBMS 서버용.
정보 베이스로 작업을 수행하는 동안 오류가 발생했습니다.
server_addr=NAME descr=11001(0x00002AF9): 이 호스트는 알 수 없습니다.
이전 오류와 마찬가지로 이 오류는 클라이언트가 서버 이름을 잘못 확인했기 때문입니다. 이번에는 클라이언트 PC였습니다. 솔루션으로 파일에 추가 /etc/hosts Linux 플랫폼 또는 C:\Windows\System32\drivers\etc\hosts플랫폼에서 Windows 항목유형:
192.168.31.83SRV-1C-1204
여기서 1C:Enterprise 서버의 주소와 이름을 지정합니다. 로컬 DNS를 사용하는 경우 추가 A 레코드서버 1C용.
DBMS 오류: DATABASE를 사용할 수 없습니다.
1C:Enterprise와 호환되지 않는 PostgreSQL 버전을 설치했거나 설치 중에 심각한 오류가 발생했음을 나타내는 훨씬 더 심각한 오류(예: 필요한 모든 종속성, 특히 라이브러리를 설치하지 않은 경우) libICU.
Linux 시스템 관리에 대한 충분한 경험이 있는 경우 필요한 라이브러리를 설치하고 DBMS 클러스터를 다시 초기화할 수 있습니다. 그렇지 않으면 PostgreSQL이 폴더의 내용을 삭제하는 것을 기억하면서 다시 설치하는 것이 좋습니다. /var/lib/pgsql.
또한 주어진 오류어셈블리를 사용할 때 발생할 수 있음 9.1.x그리고 9.2.x [이메일 보호됨]
, 자세한 내용은 아래를 참조하십시오.
DBMS 오류:
오류: "/usr/lib/x86_64-linux-gnu/postgresql/fasttrun.so" 라이브러리를 로드할 수 없습니다.
어셈블리와 관련된 매우 구체적인 오류 9.1.x그리고 9.2.x [이메일 보호됨]
, 이전 오류가 발생할 수도 있습니다. 그 이유는 fasttrun.so 라이브러리의 수정되지 않은 버그에 있습니다. 해결책은 어셈블리로 롤백하는 것입니다. 9.0.x [이메일 보호됨]
.
DBMS 오류
오류: 문자 31에 "mvarchar" 유형이 없습니다.
1C:Enterprise 시스템의 도움 없이 데이터베이스가 생성된 경우 발생합니다. 1C로 작업하려면 1C 플랫폼의 도구를 사용해서만 데이터베이스를 생성해야 함을 기억하십시오. 콘솔을 통해
또는 1C 런처를 통해.
데이터베이스 서버를 찾을 수 없습니다.
중요: 사용자 "postgres"가 인증되지 않았습니다(비밀번호로)
고도로 단순한 실수. 수퍼유저 암호가 올바르지 않습니다. DBMS 포스트그레스. 두 가지 가능한 해결책이 있습니다. 암호를 기억하거나 변경하십시오. 두 번째 경우에는 스냅인을 통해 모든 기존 정보 베이스의 속성에서 암호를 변경해야 합니다. 1C 엔터프라이즈 서버 관리.
데이터베이스 서버를 찾을 수 없습니다.
치명적: "NAME" 데이터베이스가 존재하지 않습니다.
또 다른 아주 간단한 실수. 그 의미는 지정된 데이터베이스가 존재하지 않는다는 사실로 축소됩니다. 대부분 데이터베이스 이름 지정 오류로 인해 발생합니다. 라는 것을 기억해야 합니다. 정보 기반클러스터의 1C와 DBMS 데이터베이스는 서로 다른 두 엔티티이며 다른 이름을 가질 수 있습니다. 또한 기억해야 할 것은 리눅스 시스템대소문자 구분 unf83그리고 UNF83두 개의 다른 이름.
보려면 JavaScript를 활성화하십시오 다음 하위 섹션에는 인증 방법에 대한 자세한 정보가 포함되어 있습니다.
19.3.1. 신뢰 인증
trust가 지정되면 PostgreSQL은 지정된 데이터베이스 사용자 이름(수퍼 사용자 이름이더라도)에 관계없이 서버에 연결하는 모든 사람이 데이터베이스에 액세스할 수 있는 권한이 있다고 가정합니다. 물론 기본 및 사용자 열에 지정된 제한 사항은 계속 작동합니다. 이 방법은 서버 연결에 대해 운영 체제 수준에서 적절한 보호가 있는 경우에만 사용해야 합니다.
신뢰 인증은 단일 사용자 워크스테이션의 로컬 연결에 매우 유용합니다. 그러나 이 방법 자체는 일반적으로 ~ 아니다여러 사용자가 있는 기계에 적합합니다. 그러나 파일 시스템 수준에서 서버의 Unix 소켓 파일에 대한 액세스를 제한하면 다중 사용자 시스템에서도 신뢰를 사용할 수 있습니다. 이렇게 하려면 섹션 18.3에 설명된 대로 unix_socket_permissions(및 가능하면 unix_socket_group) 구성 매개변수를 설정합니다. 또는 적절하게 보호된 디렉토리에 소켓 파일을 배치하도록 unix_socket_directories 구성 옵션을 설정할 수 있습니다.
파일 시스템 수준에서 권한을 설정하는 것은 Unix 소켓 연결에만 도움이 됩니다. 로컬 TCP/IP 연결은 파일 시스템 제한의 영향을 받지 않습니다. 따라서 로컬 보안을 위해 파일 시스템 권한을 사용하려면 pg_hba.conf에서 host ... 127.0.0.1 ... 행을 제거하거나 인증 방법을 변경하십시오.
TCP/IP 연결에 대한 신뢰 인증 방법은 신뢰 방법을 지정하는 pg_hba.conf 파일의 줄에 의해 서버에 연결할 수 있는 권한이 부여된 컴퓨터의 모든 사용자를 신뢰하는 경우에만 유효합니다. localhost(127.0.0.1) 이외의 TCP/IP 연결에는 신뢰를 사용해서는 안 됩니다.
19.3.2. 비밀번호 인증
비밀번호 인증 방법은 md5 와 password 입니다. 이러한 방법은 유사한 방식으로 작동합니다. 차이점은 암호가 통신 채널을 통해 전송되는 방식, 즉 각각 MD5 해시 형식 또는 일반 텍스트로 전송된다는 것뿐입니다.
트래픽 가로채기의 가능성이 우려된다면 md5 방식을 사용하는 것이 바람직하다. 간단한 방법비밀번호는 가능하면 항상 피해야 합니다. 그러나 md5는 db_user_namespace 옵션과 함께 사용할 수 없습니다. 연결이 SSL을 통해 암호화된 경우 비밀번호도 안전하게 사용할 수 있습니다(SSL 인증서를 통한 인증은 최고의 선택 SSL 사용에 의존하는 사람들을 위해).
PostgreSQL 비밀번호 데이터베이스는 운영 체제 사용자 비밀번호와 별개입니다. 각 데이터베이스 사용자의 비밀번호는 pg_authid 시스템 디렉토리에 저장됩니다. 다음을 통해 비밀번호로 작업할 수 있습니다. SQL 명령예를 들어 CREATE USER 및 ALTER ROLE 비밀번호 "비밀"로 사용자 foo 만들기. 사용자에 대해 암호가 설정되지 않은 경우 암호는 null로 저장되고 해당 사용자에 대한 암호 인증은 불가능합니다.
19.3.3. GSSAPI 인증
GSSAPI는 RFC 2743에 정의된 보안 인증을 위한 업계 표준 프로토콜입니다. PostgreSQL은 RFC 1964에 따라 Kerberos 인증을 사용하여 GSSAPI를 지원합니다. GSSAPI는 이를 지원하는 시스템에 대해 자동 인증(싱글 사인온)을 제공합니다. 인증 자체는 안전하지만 데이터베이스 연결 중에 전송되는 데이터는 SSL을 사용하지 않는 한 안전하지 않습니다.
Postgres Pro Standard를 빌드할 때 GSSAPI 지원을 활성화해야 합니다.
Kerberos로 작업할 때 GSSAPI는 다음 형식의 표준 계정을 사용합니다. 서비스 이름/호스트 이름@영역. PostgreSQL 서버는 서버에서 사용하는 키맵 파일에 포함된 모든 주체를 수락하지만 krbsrvname 연결 옵션을 사용하여 클라이언트에 연결할 때 올바른 주체 세부 정보를 제공하도록 주의해야 합니다. (하위 섹션 31.1.2도 참조하십시오.) 기본 postgres 서비스 이름 값은 ./configure --with-krb-srvnam=를 사용하여 빌드 시 변경할 수 있습니다. 무엇이든. 대부분의 환경에서 변경 주어진 매개변수필요하지 않습니다. 그러나 일부 Kerberos 구현에는 다른 서비스 이름이 필요할 수 있습니다. 예를 들어 Microsoft Active Directory에서는 서비스 이름이 대문자(POSTGRES)여야 합니다.
호스트 이름여기 완전한 도메인 이름서버가 실행되는 컴퓨터. 서비스 주체의 영역은 컴퓨터의 기본 영역입니다.
클라이언트 보안 주체는 pg_ident.conf의 다양한 PostgreSQL 데이터베이스 사용자 이름에 매핑될 수 있습니다. 예를 들어 교장 [이메일 보호됨] pgusername과만 일치시킬 수 있습니다. PostgreSQL에서 전체 주체 이름을 역할 이름으로 사용할 수도 있습니다. [이메일 보호됨]비교도 없이.
PostgreSQL은 주체 이름에서 영역을 제거하는 기능도 지원합니다. 이 기능은 이전 버전과의 호환성을 위해 예약되어 있으며 이름은 같지만 다른 영역에서 온 다른 사용자를 구별할 수 없기 때문에 매우 바람직하지 않습니다. 활성화하려면 include_realm을 0으로 설정하십시오. 간단한 구성단일 영역에서 영역 제외를 krb_realm 매개변수(krb_realm 매개변수에 설정된 단일 값으로 제한할 수 있음)와 함께 사용하는 것이 pg_ident.conf 의 명시적 매핑보다 안전하지만 덜 유연한 옵션입니다.
Postgres Pro 서버 계정에서 서버의 키 파일을 읽을 수 있는지(그리고 가급적이면 쓸 수 없는지) 확인하십시오. (섹션 17.1 참조.) 이 키 파일의 위치는 krb_server_keyfile 매개변수에 의해 지정됩니다. 기본값은 /usr/local/pgsql/etc/krb5.keytab입니다(디렉토리는 빌드 중 설정한 sysconfdir에 따라 다를 수 있음). 보안상의 이유로 다음을 사용하는 것이 좋습니다. 별도 파일시스템 전체 파일을 노출하는 대신 Postgres Pro 서버용 keytab.
키 테이블 파일이 생성됩니다. 소프트웨어케르베로스; 이는 Kerberos 설명서에 자세히 설명되어 있습니다. 다음 예는 Kerberos 5의 MIT 호환 구현을 위한 것입니다.
Kadmin% ank -randkey postgres/server.my.domain.org kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org
데이터베이스에 연결할 때 보안 주체를 데이터베이스 사용자 이름에 매핑할 수 있는 권한이 있는지 확인하십시오. 예를 들어 데이터베이스 사용자 이름 fred 의 경우 보안 주체 [이메일 보호됨]연결할 수 있을 것입니다. 프린시펄 fred/에게 연결 권한을 부여하려면 [이메일 보호됨], 섹션 19.2에 설명된 대로 사용자 이름 매핑 파일을 사용합니다.
GSSAPI 방법 사용 가능 다음 옵션구성:
include_realm
섹션 19.2). 이 옵션은 krb_realm이 추가로 지정되지 않는 한 다중 영역 환경에서 안전하지 않기 때문에 권장되지 않으며 주로 이전 버전과의 호환성을 위해 지원됩니다. 기본 옵션은 include_realm을 기본값 1로 두고 pg_ident.conf를 명시적 매핑으로 설정하여 주체 이름을 Postgres Pro 사용자 이름으로 변환하는 것입니다. 지도
시스템 사용자 이름과 데이터베이스 사용자 간의 매핑을 허용합니다. 자세한 내용은 섹션 19.2를 참조하십시오. 다음과 같은 GSSAPI/Kerberos 주체의 경우 [이메일 보호됨](또는 더 희귀한 사용자 이름/ [이메일 보호됨]), 매핑의 사용자 이름은 [이메일 보호됨](또는 사용자 이름/ [이메일 보호됨], 각각) include_realm이 0이 아닌 경우; 그렇지 않으면 맵의 시스템 사용자 이름은 사용자 이름(또는 사용자 이름/호스트 기반)이 됩니다. krb_realm
19.3.4. SSPI 인증
SSPI는 안전한 싱글 사인온 인증을 위한 Windows 기술입니다. PostgreSQL은 가능한 경우 Kerberos를 사용하고 그렇지 않으면 자동으로 NTLM으로 폴백하는 협상 모드에서 SSPI를 사용합니다. SSPI 인증은 서버와 클라이언트가 모두 Windows 플랫폼에서 실행 중이거나 GSSAPI를 사용할 수 있는 경우 Windows가 아닌 플랫폼에서 실행 중인 경우에만 작동합니다.
SSPI에 대해 다음 구성 옵션을 사용할 수 있습니다.
include_realm
이 매개변수가 0으로 설정되면 인증된 사용자의 보안 주체에서 영역이 제거되고 나머지 이름은 이름 일치를 거칩니다(섹션 19.2 참조). 이 옵션은 krb_realm이 추가로 지정되지 않는 한 다중 영역 환경에서 안전하지 않기 때문에 권장되지 않으며 주로 이전 버전과의 호환성을 위해 지원됩니다. 기본 옵션은 include_realm을 기본값 1로 두고 pg_ident.conf를 명시적 매핑으로 설정하여 주체 이름을 Postgres Pro 사용자 이름으로 변환하는 것입니다. compat_realm
1로 설정하면 SAM 호환 도메인 이름(NetBIOS 이름이라고도 함)이 include_realm 매개변수에 사용됩니다. 이것은 기본 옵션입니다. 0이면 실제 영역 이름이 Kerberos 주체 이름에 사용됩니다.
이 설정은 서버가 도메인 사용자(도메인에 가입된 컴퓨터의 서비스 가상 사용자 포함)로 실행되고 SSPI를 통해 인증하는 모든 클라이언트도 도메인 계정을 사용하는 경우에만 비활성화할 수 있습니다. 그렇지 않으면 인증이 실패합니다. upn_username
이 옵션이 compat_realm 과 함께 활성화되면 Kerberos UPN 이름이 인증에 사용됩니다. 비활성화된 경우(기본값) SAM 호환 사용자 이름이 사용됩니다. 기본적으로 새 계정의 이름은 같습니다.
이름이 명시적으로 지정되지 않은 경우 libpq는 SAM 호환 이름을 사용합니다. libpq 또는 이를 기반으로 하는 드라이버를 사용하는 경우 이 옵션을 비활성화하거나 연결 문자열에서 사용자 이름을 명시적으로 설정해야 합니다. 지도
시스템 사용자를 데이터베이스 사용자에 매핑할 수 있습니다. 자세한 내용은 섹션 19.2를 참조하십시오. 다음과 같은 SSPI/Kerberos 주체의 경우 [이메일 보호됨](또는 더 희귀한 사용자 이름/ [이메일 보호됨]), 매핑의 사용자 이름은 [이메일 보호됨](또는 사용자 이름/ [이메일 보호됨], 각각) include_realm이 0이 아닌 경우; 그렇지 않으면 맵의 시스템 사용자 이름은 사용자 이름(또는 사용자 이름/호스트 기반)이 됩니다. krb_realm
사용자 프린시펄 이름을 확인할 영역을 설정합니다. 이 설정이 지정되면 해당 영역의 사용자만 연결할 수 있습니다. 설정하지 않으면 설정된 사용자 이름 매핑에 따라 모든 영역의 사용자가 연결할 수 있습니다.
19.3.5. 본인인증
ident 인증 방법은 Ident 서버에서 클라이언트의 운영 체제 사용자 이름을 가져와 확인된 데이터베이스 사용자 이름으로 사용하여 작동합니다(가능한 사용자 이름 일치 포함). 이 방법은 TCP/IP 연결에만 사용할 수 있습니다.
메모
언제 로컬 연결(TCP/IP 아님) ident가 지정되면 피어 인증 방법이 대신 사용됩니다(19.3.6항 참조).
ident 메서드에 사용할 수 있는 구성 옵션은 다음과 같습니다.
지도
섹션 19.2.
규약 " 식별 »(Ident)는 RFC 1413에 설명되어 있습니다. 거의 모든 유닉스 계열 운영 체제에는 기본적으로 TCP 포트 113에서 수신 대기하는 Ident 서버가 함께 제공됩니다. 이 서버의 기본 기능은 다음과 같은 질문에 답하는 것입니다. « 포트를 통해 연결을 시작한 사용자 엑스내 포트에 연결 와이?
»
. 물리적 연결이 설정되면 PostgreSQL은 엑스, 그리고 와이, 클라이언트 컴퓨터의 Ident 서버를 쿼리할 수 있으며 이론적으로 각 연결에서 운영 체제 사용자를 결정할 수 있습니다.
이 절차의 단점은 클라이언트와의 통합에 의존한다는 것입니다. 클라이언트 머신신뢰할 수 없거나 손상되지 않은 경우 공격자는 포트 113에서 모든 프로그램을 실행하고 원하는 사용자 이름을 반환할 수 있습니다. 따라서 이 인증 방법은 각 클라이언트 시스템이 엄격하게 제어되고 운영 체제와 데이터베이스 관리자가 긴밀하게 접촉하는 폐쇄된 네트워크에만 적합합니다. 즉, Ident 서버가 실행 중인 시스템을 신뢰해야 합니다. 다음 경고를 기억하십시오.
일부 Ident 서버에는 관리자에게만 알려진 키를 사용하여 반환된 사용자 이름을 암호화할 수 있는 비표준 기능이 있습니다. 소스 컴퓨터. 이 기회 그것은 금지되어 있습니다 Postgres Pro는 반환된 문자열을 디코딩하고 실제 사용자 이름을 가져올 수 없기 때문에 Postgres Pro와 함께 사용하십시오.
19.3.6. 피어 인증
피어 인증 방법은 커널에서 클라이언트 운영 체제의 사용자 이름을 가져와 확인된 데이터베이스 사용자 이름으로 사용하여 작동합니다(사용자 이름 일치 포함). 이 방법은 로컬 연결에만 지원됩니다.
피어 메서드에 대해 다음 구성 옵션을 사용할 수 있습니다.
지도
시스템 및 데이터베이스 사용자 이름을 일치시킬 수 있습니다. 자세한 내용은 섹션 19.2를 참조하십시오.
피어 인증은 다음에서만 사용할 수 있습니다. 운영체제 getpeereid() 함수, SO_PEERCRED 소켓 옵션 또는 유사한 메커니즘을 지원합니다. 현재 Linux , OS X 및 Solaris 를 포함한 대부분 의 BSD 맛 .
19.3.7. LDAP 인증
이 방법인증 방법은 암호 확인 방법으로 LDAP를 사용한다는 점을 제외하면 암호 방법과 유사한 방식으로 작동합니다. LDAP는 사용자 이름/암호 쌍을 확인하는 데만 사용됩니다. 따라서 LDAP가 인증에 사용되기 전에 사용자가 데이터베이스에 이미 존재해야 합니다.
LDAP 인증은 두 가지 모드에서 작동할 수 있습니다. 첫 번째 모드를 단순 바인딩이라고 합니다. 인증하는 동안 서버는 다음과 같이 구성된 고유 이름과 연결됩니다. 접두사 사용자 이름 접미사. 일반적으로 매개변수 접두사 cn= 또는 도메인\ Active Directory 환경에서. 접미사나머지 DN을 지정하거나 Active Directory 이외의 환경에서 사용됩니다.
search+bind라고 하는 두 번째 모드에서 서버는 먼저 사전 정의된 사용자 이름과 암호가 지정된 LDAP 디렉토리에 바인딩합니다. ldapbinddn그리고 ldapbindpasswd, 데이터베이스에 연결하려는 사용자를 검색합니다. 사용자 이름과 암호가 지정되지 않은 경우 서버는 익명으로 디렉토리에 접속을 시도합니다. 검색은 하위 트리에서 수행됩니다. LDAP 기반, 속성에 대한 사용자 이름의 정확한 일치를 확인하는 동안 ldapsearch속성. 조회에서 사용자가 발견되면 서버는 연결을 끊고 해당 사용자로 디렉터리에 다시 연결하고 클라이언트가 암호를 전달하여 계정이 올바른지 확인합니다. Apache의 pam_ldap 및 mod_authnz_ldap과 같은 다른 소프트웨어의 LDAP 인증 체계에서 동일한 모드가 사용됩니다. 이 옵션을 사용하면 사용자 개체의 위치를 더 유연하게 선택할 수 있지만 LDAP 서버에 두 번 연결해야 합니다.
두 모드 모두에서 인증할 때 다음 구성 옵션을 사용할 수 있습니다.
LDAP 서버
통신을 위한 LDAP 서버의 이름 및 IP 주소. 공백으로 구분하여 여러 서버를 지정할 수 있습니다. ldapport
LDAP 서버와 통신하기 위한 포트 번호입니다. 포트를 지정하지 않으면 기본 LDAP 라이브러리 포트가 사용됩니다. LDAP
TLS 암호화를 사용하여 Postgres Pro와 LDAP 서버 간에 연결을 설정하려면 1로 설정합니다. 이는 LDAP 서버와의 통신만 암호화하며 SSL을 사용하지 않는 한 클라이언트 연결은 암호화되지 않은 상태로 유지됩니다.
다음 구성 옵션은 단순 바인딩 모드 인증에서만 사용할 수 있습니다.
Ldapprefix
이 문자열은 단순 바인드 인증을 위한 바인드 DN을 생성할 때 사용자 이름 앞에 대체됩니다. ldapsuffix
이 문자열은 단순 바인드 모드에서 인증할 때 바인드 DN을 형성하는 동안 사용자 이름 뒤에 배치됩니다.
다음 구성 옵션은 검색+바인드 인증에서만 사용할 수 있습니다.
LDAP 기반
검색+바인드 인증에서 사용자 검색을 시작하기 위한 루트 DN입니다. ldapbinddn
조회+바인드 인증 중 조회를 수행할 때 디렉토리에 바인딩할 사용자의 DN입니다. ldapbindpasswd
검색+바인드 인증 중 검색을 수행할 때 사용자가 디렉터리에 바인딩하기 위한 암호입니다. ldapsearch속성
조회+바인드 인증 중에 사용자 이름과 일치시킬 속성입니다. 속성을 지정하지 않으면 uid 속성이 사용됩니다. ldapurl
RFC 4516 LDAP 주소. 이것은 보다 간결하고 표준적인 방식으로 일부 LDAP 기능을 작성하는 대체 방법입니다. 녹음 형식은 다음과 같습니다.
ldap:// 주최자[:포트]/기반을 둔[?[속성][?[범위]]]
범위 base , one 또는 sub 이어야 합니다. 일반적으로 마지막입니다. 하나의 속성이 사용되며 필터 및 확장과 같은 표준 LDAP 주소의 일부 구성 요소는 지원되지 않습니다.
비익명 바인딩의 경우 ldapbinddn 및 ldapbindpasswd를 별도의 옵션으로 지정해야 합니다.
암호화된 LDAP 연결을 사용하려면 ldapurl 옵션과 함께 ldaptls 옵션을 사용해야 합니다. ldaps URL 체계(직접 SSL 연결)는 지원되지 않습니다.
현재 LDAP URL은 Windows가 아닌 OpenLDAP에서만 지원됩니다.
단순 연결 모드의 구성 설정과 검색+연결 모드의 설정을 혼동하면 안 됩니다. 이는 실수입니다.
다음은 단순 바인드에 대한 LDAP 구성의 예입니다.
호스트 ... ldap ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
데이터베이스 사용자 someuser 로 데이터베이스 서버에 대한 연결이 요청되면 PostgreSQL은 DN cn=someuser, dc=example, dc=net 및 클라이언트가 제공한 비밀번호를 사용하여 LDAP 서버에 연결을 시도합니다. 이 연결이 성공하면 데이터베이스에 대한 액세스가 열립니다.
검색+바인딩 모드의 구성 예:
호스트 ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchattribute=uid
데이터베이스 사용자 someuser로 데이터베이스 서버에 대한 연결이 요청되면 PostgreSQL은 익명으로 LDAP 서버에 접속을 시도하고(ldapbinddn이 지정되지 않았기 때문에) 지정된 기본 DN에서 (uid=someuser)를 검색합니다. 항목이 발견되면 찾은 정보와 클라이언트가 제공한 암호를 사용하여 바인딩을 시도합니다. 두 번째 연결 시도가 성공하면 데이터베이스에 대한 액세스 권한이 부여됩니다.
검색+링크 모드에 대한 동일한 구성의 예이지만 URL로 작성되었습니다.
호스트 ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"
이 URL 형식은 LDAP 인증을 지원하는 다른 소프트웨어에서도 사용되므로 이 구성을 더 쉽게 배포할 수 있습니다.
단서
LDAP는 종종 쉼표와 공백을 사용하여 DN의 다른 부분을 구분하기 때문에 예제와 같이 옵션 값을 지정할 때 따옴표를 사용해야 합니다.
19.3.8. RADIUS 인증
이 인증 방법은 RADIUS를 암호 확인 방법으로 사용한다는 점을 제외하면 암호 방법과 유사한 방식으로 작동합니다. RADIUS는 사용자 이름/암호 쌍을 확인하는 데만 사용됩니다. 따라서 RADIUS가 인증에 사용되기 전에 사용자가 데이터베이스에 이미 존재해야 합니다.
RADIUS 인증 중에 액세스 요청이 구성된 RADIUS 서버로 전송됩니다. 이 메시지는 인증 전용 유형이며 사용자 이름, 암호(암호화됨) 및 NAS ID 매개변수를 포함합니다. 요청은 서버와 공유되는 비밀을 사용하여 암호화됩니다. RADIUS 서버는 액세스 허용 또는 액세스 거부로 서버의 요청에 응답합니다. RADIUS 계정 시스템은 지원되지 않습니다.
RADIUS 방법에 대해 다음 구성 옵션을 사용할 수 있습니다.
반경 서버
연결할 RADIUS 서버의 이름 또는 IP 주소입니다. 이것은 필수 매개변수입니다. 반지름비밀
RADIUS 서버에 연결할 때 사용되는 공유 암호입니다. Postgres Pro 및 RADIUS 서버 모두에서 동일한 값을 가져야 합니다. 16자 이상의 문자열을 사용하는 것이 좋습니다. 이것은 필수 매개변수입니다.
메모
암호화 벡터는 PostgreSQL이 OpenSSL 지원으로 구축된 경우에만 효과적입니다. 그렇지 않으면 RADIUS 서버로의 데이터 전송은 마스킹만 되고 보호되지 않으므로 추가 보안 조치를 취해야 합니다.
반경 포트 RADIUS 서버와 통신하기 위한 포트 번호입니다. 포트를 지정하지 않으면 기본적으로 포트 1812가 사용됩니다. 반경식별자
RADIUS 서버에서 사용되는 문자열은 NAS ID로 쿼리합니다. 이 매개변수는 예를 들어 어떤 사용자가 어떤 데이터베이스 사용자로 연결을 시도하는지 식별하기 위한 두 번째 매개변수로 사용될 수 있으며, 이는 RADIUS 서버에서 일치를 형성하는 데 사용할 수 있습니다. ID를 지정하지 않으면 기본값은 postgresql 입니다.
19.3.9. 인증서 인증
이 방법은 인증을 위해 SSL 클라이언트 인증서를 사용하므로 이 방법은 SSL 연결에만 적용됩니다. 이 방법을 사용하면 서버는 클라이언트가 유효하고 신뢰할 수 있는 인증서를 제시하도록 요구합니다. 클라이언트에 암호를 묻는 메시지가 표시되지 않습니다. 인증서의 cn(Common Name) 속성을 요청한 데이터베이스 사용자 이름과 비교하여 일치하면 로그인이 허용됩니다. cn이 데이터베이스 사용자 이름과 다른 경우 사용자 이름 매핑을 사용할 수 있습니다.
SSL 인증서 인증에 사용할 수 있는 구성 옵션은 다음과 같습니다.
지도
시스템 및 데이터베이스 사용자 이름을 일치시킬 수 있습니다. 자세한 내용은 섹션 19.2를 참조하십시오.
인증서 인증을 위한 pg_hba.conf 항목은 clientcert 매개변수를 1로 가정하고 이 방법에 클라이언트 인증서가 필요하기 때문에 비활성화할 수 없습니다. cert 메서드는 cn 속성이 데이터베이스 사용자 이름과 일치하는지 여부도 확인한다는 점에서 단순한 clientcert 인증서 유효성 검사와 다릅니다.
19.3.10. PAM 인증
이 인증 방법은 암호 방법처럼 작동하지만 PAM(Pluggable Authentication Modules)을 인증 메커니즘으로 사용합니다. 기본 PAM 서비스 이름은 postgresql 입니다. PAM은 사용자 이름/암호 쌍을 확인하는 데만 사용되며 선택적으로 원격 컴퓨터의 이름이나 IP 주소를 확인할 수 있습니다. 따라서 PAM을 인증에 사용하려면 사용자가 데이터베이스에 이미 존재해야 합니다. PAM에 대한 자세한 내용은 Linux-PAM 설명 페이지를 참조하십시오.
PAM 인증에 사용할 수 있는 구성 옵션은 다음과 같습니다.
팜서비스
PAM 서비스 이름 pam_use_hostname
원격 컴퓨터의 IP 주소 또는 이름이 PAM_RHOST 필드를 통해 PAM 모듈에 제공되는지 여부를 지정합니다. 기본값은 IP 주소입니다. 호스트 이름을 사용하려면 이 매개변수를 1로 설정하십시오. 호스트 이름 확인으로 인해 연결이 지연될 수 있습니다. (일반적으로 PAM 구성은 이 정보를 사용하지 않으므로 이 정보를 사용하는 사용자 지정 구성이 생성된 경우에만 이 설정을 고려해야 합니다.)
메모
PAM이 /etc/shadow 를 읽도록 구성된 경우 PostgreSQL 서버가 루트로 실행되고 있지 않기 때문에 인증이 실패합니다. 그러나 PAM이 LDAP 또는 기타 인증 방법을 사용하도록 구성된 경우에는 중요하지 않습니다.
19.3.11. BSD 인증
이 인증 방법은 암호 방법처럼 작동하지만 BSD 인증 메커니즘을 사용하여 암호를 확인합니다. BSD 인증은 사용자 이름/암호 쌍을 확인하는 데만 사용됩니다. 따라서 이 인증이 성공하려면 사용자 역할이 데이터베이스에 이미 존재해야 합니다. BSD 인증 메커니즘은 현재 OpenBSD에만 적용됩니다.
BSD 인증을 위해 PostgreSQL은 login.conf에 정의된 경우 auth-postgresql 로그인 유형과 postgresql 클래스를 사용합니다. 기본적으로 이 로그인 클래스는 존재하지 않으며 PostgreSQL은 기본 로그인 클래스를 사용합니다.
메모
BSD 인증을 사용하려면 먼저 다음을 추가해야 합니다. 계정 Postgres Pro 사용자(즉, 서버를 실행하는 OS 사용자)를 인증 그룹에 추가합니다. 인증 그룹은 기본적으로 OpenBSD 시스템에 존재합니다.
