2 posts tagged with "access-denied"

Amazon의 S3 서비스를 사용할 때 기본 설정만으로는 upload 한 파일에 대한 접근이 안된다.

Permission 설정이 있길래 건드려 보기도 했는데 permission 만으로는 해결할 수 없었다.

이 부분은 조금 이상하다. 많은 사람들이 permission 설정만으로 접근 권한 제어가 가능할거라 인식할 거라고 보기 때문이다.

또 서비스들이 계속 변경되어서 그런지 검색을 통해 얻는 정보들이 부정확한 것들이 많아서 정리해보기로 했다.

1. 현상

Browser로 간편하게 확인해보기 위해 image를 upload 했다.

그 image의 properties를 확인하면 기본 정보들이 표시되는데 그 중에 link를 열어보면 아래와 같은 화면이 나타난다.

XML 형태로 output을 내주고 있는데 AccessDenied로 표시하고 있다.

2. Policy 설정

결론부터 얘기하면 모든 resource는 기본적으로 private이라 policy 설정을 해야 접근이 가능한 것으로 보인다. Policy는 (S3에서 얘기하는) bucket 마다 설정이 가능한데, 하위의 디렉토리나 각각의 파일에 대해서는 설정할 수 없다. Bucket의 Properties를 열고 Permission 항목을 확인하면 bucket policy 추가하는 버튼이 있다.

버튼을 눌러보면 텍스트 입력 팝업이 나타나고 하단에 AWS Policy Generator가 보이는데 처음이라 policy의 형식을 잘 모르니 generator를 사용해봤다. Generator를 열어서 필요한 입력 필드에 원하는 정보를 입력한다.

Principal은 policy 적용 대상(사용자)을 의미하는데 익명 사용자에 대해 지정하고 싶다면 *로 입력하고, ARN (Amazon Resource Name)은 표시된 형식대로 입력한다. (arn:aws:s3:::<bucket_name>/<key_name>) Action은 S3에 대한 약간의 지식이 필요한데, 이미지 표시 및 다운로드 (어차피 같은 의미)만 테스트 해볼 것이므로 GetObject를 선택한다. ARN의 key_name은 resource에 대한 key를 의미하는 것으로 보인다. 나의 경우엔 특정 디렉토리에 있는 모든 image를 대상으로 하므로 arn:aws:s3:::my_bucket/sub/dir/* 형태로 입력했다.

모든 필드를 채워서 Generate Policy 버튼을 누르면 S3에서 원하는 형식의 텍스트를 표시해준다. 복사해서 이전의 Bucket Policy Editor에 붙여넣기 한 후 저장하면 적용됨.

3. 결과

아까 전 AccessDenied 응답을 받았던 link를 그대로 열어보면 image가 제대로 browser에서 표시된다. 다른 사용자나 특정 referer에 대한 허가, 거부 등의 세밀한 조정이 필요할 수 있겠다 싶은데 그 부분은 Example Cases for Amazon S3 Bucket Policies를 좀 더 참고해봐야한다.

국내에서는 많이 사용하지 않는 Open source RDBMS인 PostgreSQL을 잠깐 사용해 볼 일이 생겼다.

설치는 어렵지 않았는데, 테이블 생성할 때 까지 몇가지 생소한게 있었다.

1. 접근 권한

PostgreSQL이 설치된 장비에서 관리도구로 접속하는건 문제가 없는데 다른 장비, PC에서 접속하는건 불가능했다.

이유는 pg_hba.conf 라는 설정파일에 존재하는 접근 권한이 기본은 다른 장비에 대해서는 막고 있기 때문이었는데 접속하려는 장비의 IP 대역이나 고정된 IP 값으로 풀어줘야 한다.

pg_hba.conf 파일 위치도 처음엔 몰라서 헤맸는데 설치 경로의 data directory 안에 존재한다.

OS X에서 설치했을 땐 data directory의 owner와 group이 PostgreSQL에서 관리되는 계정과 그룹이라 sudo 권한으로 vi 편집기로 수정해서 사용할 수 밖에 없었는데, 기본 제공되는 관리도구인 pgAdmin이 보여준 몇 가지 문제점 때문이기도 했다.

2. Auto increment

MySQL에서는 column 생성할 때 auto increment 속성 지정이 가능했던 것으로 기억한다. 속성을 지정하면 따로 값을 insert 하지 않아도 초기값부터 증분만큼 자동 증가하게 되어있는데 PostgreSQL은 아무리 뒤져도 그런 속성이나 혹시나 해서 찾아본 data type에도 존재하지 않았다.

PostgreSQL에서는 auto increment 하기 위한 sequence 라는 것을 먼저 정의하고 column 생성시 그 sequence를 nextval 이라는 내장 함수로 호출하도록 해야 한다.

결론

잠깐 살펴봤을 때 PostgreSQL은 전체적으로 관리나 DB 설계 측면에서 좀 더 세밀한 설정과 구축을 하도록 권유하는 느낌이다.

PostgreSQL과 MySQL의 장단점, 뭐가 좋으냐 나쁘냐를 두고 인터넷 여기저기에서 말이 많은데, 결국은 일정과 규모에 따라서 나에게 익숙하거나 trouble shooting에 필요할지 모를 reference가 많으냐 적으냐에 따라서 골라쓰면 되지 않을까? 라는 생각을 잠깐 해본다. DB만 전문적으로 하시는 분들은 뭣도 모르는 소리라고 할지 모르겠지만 나 같은 초보자야 뭐.

Updated : 2013-04-16

serial과 bigserial type은 true type은 아니고 각각 4byte와 8byte data 저장이 가능하다. PostgreSQL Document에 따르면 다른 RDBMS의 auto_increment와 유사한 속성을 가지는데 아래의 두 query가 동일한 의미를 갖는다고 되어있다.

CREATE TABLE tablename (
    colname SERIAL
);

CREATE SEQUENCE tablename_colname_seq;
CREATE TABLE tablename (
    colname integer NOT NULL DEFAULT nextval('tablename_colname_seq')
);
ALTER SEQUENCE tablename_colname_seq OWNED BY tablename.colname;

댓글을 달아주신 분의 말씀처럼 auto_increment 대신 사용이 가능하다.