2018년 8월 19일 일요일

Eclipse cannot open git-upload-pack 오류: 인증·인증서·프록시 확인

cannot open git-upload-pack만으로 원인을 단정할 수 없습니다. Eclipse의 Error Log에서 함께 나온 메시지를 확인한 뒤 저장소 주소, 인증, 인증서, 프록시 순서로 범위를 좁혀 보세요.

2026년 10월 16일 수정: 이 글의 예전 내용은 http.sslVerify=false 설정만 안내했습니다. 인증서 검증을 끄는 방법을 일반 해결책으로 제시한 부분을 바로잡았습니다.

1. 상세 오류부터 확인하기

Eclipse의 Error Log 보기에서 실패한 시각의 예외와 하위 원인을 확인합니다. 사용 중인 Eclipse·EGit·Java 버전, HTTPS인지 SSH인지도 함께 기록하세요. 오류 로그를 공유할 때 토큰·비밀번호·내부 주소는 가립니다.

  • 401 또는 인증 실패: 계정과 인증 수단을 확인합니다.
  • 403 또는 저장소 접근 거부: 계정의 접근 권한과 조직 정책을 확인합니다.
  • 404 또는 저장소를 찾을 수 없음: 복제 URL과 접근 권한을 함께 확인합니다. 비공개 저장소는 권한 문제도 의심해야 합니다.
  • 인증서·PKIX 관련 메시지: 서버 인증서와 Eclipse가 사용하는 Java 환경의 신뢰 설정을 확인합니다.
  • 타임아웃·호스트 조회 실패: 네트워크와 프록시 설정을 확인합니다.

이 목록은 진단 순서이며 각 메시지의 원인이 하나로 정해진다는 뜻은 아닙니다.

2. URL과 인증 확인하기

저장소 서비스에서 복제 URL을 다시 확인합니다. GitHub HTTPS 인증에서 토큰을 요구하는 경우 일반 계정 비밀번호 대신 적절한 권한의 토큰을 사용합니다. 토큰을 URL에 직접 넣지 말고 인증 입력란이나 지원되는 자격 증명 저장소를 사용하세요.

명령줄 Git이 설치되어 있다면 같은 저장소 폴더에서 아래 읽기 전용 조회로 비교할 수 있습니다. 출력에는 사설 저장소 주소가 포함될 수 있습니다.

git remote -v
git ls-remote origin

명령줄에서는 성공하고 Eclipse에서 실패해도 서버가 완전히 정상이라고 단정할 수는 없습니다. 두 도구가 사용하는 인증 저장소·프록시·인증서 환경을 비교하는 단서로 사용하세요.

3. 인증서 검증을 끄기보다 신뢰 경로 확인하기

Git의 http.sslVerify는 HTTPS 인증서 검증 여부이며 기본값은 true입니다. 인증서 오류라면 서버의 만료·호스트 이름·체인 설정을 확인하고, 사내 인증서를 사용하는 환경에서는 관리자가 제공한 신뢰 설정을 따르세요. EGit의 HTTP 구현과 Java 실행 환경도 확인 대상입니다.

이전 글을 따라 검증을 껐다면 해당 설정의 위치와 적용 범위를 확인해 해제한 설정을 되돌리세요. 인증 문제가 해결되는지 확인하지 않고 전역 설정을 반복 변경하지 마세요.

4. 프록시와 재확인

회사 네트워크에서만 실패한다면 Eclipse의 Preferences → General → Network Connections를 확인합니다. EGit은 HTTP 연결 구현에 따라 프록시 동작이 다를 수 있습니다. 설정을 하나씩 바꾸며 동일한 조회로 결과를 비교하세요.

이 글은 공식 문서에 근거한 진단 안내입니다. 특정 Eclipse 설치에서 같은 장애를 재현해 해결했다고 주장하는 글은 아닙니다.

공식 참고 문서

MySQL CSV 내보내기: INTO OUTFILE과 secure_file_priv 오류 확인

MySQL의 SELECT ... INTO OUTFILE은 DB 서버에 파일을 만듭니다. 내 PC의 다운로드 폴더로 받는 기능으로 생각하면 경로와 권한 문제를 혼동하기 쉽습니다. 먼저 서버의 출력 허용 경로를 확인하세요.

2018년 추천 알고리즘용 CSV 추출 경험을 남긴 글에 2026년 10월 16일 진단 절차를 보완했습니다. 아래 체크는 MySQL 8.4 공식 문서를 기준으로 정리했으며, 이번에 운영 DB에서 내보내기를 실행한 것은 아닙니다.

Error 1290이 나면 먼저 확인할 값

SELECT @@secure_file_priv;

출력 허용 디렉터리가 지정되어 있다면 그 안의 새 파일 경로를 사용해야 합니다. 또한 파일 출력에 필요한 권한, 서버 프로세스의 디렉터리 쓰기 권한, 같은 이름의 파일이 이미 있는지를 확인합니다. 원격 서버를 쓰고 있다면 경로도 원격 서버 기준입니다.

에러 메시지 전체를 확인하지 않고 설정 제한을 해제하거나 데이터베이스를 재시작하는 것부터 시도하지 마세요. 관리형 서비스 등 파일 출력이 허용되지 않는 환경이라면 사용 중인 클라이언트의 결과 내보내기 기능을 검토합니다.

CSV를 만든 뒤 확인할 항목

  • 문자 인코딩: 기존 예제의 EUC-KR은 당시 소비 프로그램에 맞춘 선택입니다. 새 내보내기는 받는 프로그램과 문자셋을 합의하세요.
  • 구분자·따옴표·이스케이프: 쉼표가 있는 데이터가 한 필드로 읽히는지 작은 샘플로 확인합니다. MySQL의 백슬래시 이스케이프 설정과 Python CSV 기본 설정을 무조건 같은 형식으로 취급하지 마세요.
  • 열 이름과 순서: 헤더 포함 여부와 열 순서를 받는 쪽과 맞춥니다. 안정된 교환 형식이 필요하다면 SELECT * 대신 열 목록을 명시하는 편이 검토하기 쉽습니다.
  • 기존 파일: OUTFILE은 기존 파일을 덮어쓰지 않습니다. 원본을 지우기보다 작업별 새 파일명을 사용하고 결과를 검증합니다.

공식 근거: MySQL 8.4 SELECT ... INTO.

당시 작업 기록

아래는 2018년 환경의 기록입니다. 경로·문자셋·서버 재시작 절차를 그대로 적용하지 말고 위의 확인 순서를 먼저 따르세요.

2018년 원문 펼치기머하웃의 간단한 아이템 기반 추천알고리즘을 적용해보는 과정에서,
알고리즘이 .csv 파일을 읽어 특정 개수의 아이템을 추천해주는 방식이었기 때문에, DB의 테이블을 .csv 파일로 뽑아내는 작업이 필요하였다. 


여기를 참고하여 데이터를 뽑았는데, 나는 첫번째 SQL을 사용하였다.

1
2
3
4
5
6
SELECT * FROM recommend_coursedata
INTO OUTFILE 'C:/MySqlOutputData/test.csv'
CHARACTER SET euckr
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
ESCAPED BY '\\'
LINES TERMINATED BY '\n';
cs
이를 실행하면 
Error Code: 1290. The MySQL server is running with the --secure-file-priv option so it cannot execute this statement

에러가 발생하는데, 파일이 생성되는 경로와 mysql서버의 secure-file-priv 경로와 달라서 발생하는 에러 같다. 

INTO OUTFILE 의 경로는 
mysql 서버의 secure_file_priv 에 명시에되어있다. 


여기서 나오는 데이터를 기준으로 추천을 해주기 때문에 관리자 계정이 버튼으로 추천 데이터를 업데이트해주자는 생각으로 진행하였다. 그렇기 때문에 버튼을 누를 때 마다 
저 경로의 파일을 지우고, 새로 파일을 생성하는 방식으로 진행하려고 하였다. 

하지만, 경로가 ProgramData 속에 있기 때문에 수정/삭제에 대해 관리자 권한이 필요하였고, 경로를 바꾸기로 하였다. 

나의 경우에는 
my.ini 
secure-file-priv 의 경로를 직접 바꾼 후 mysql을 재시작하여 진행하였다. 


2018년 8월 12일 일요일

EJB / bean

엔터프라이즈 자바빈즈

위키백과, 우리 모두의 백과사전.
둘러보기로 가기검색하러 가기
엔터프라이즈 자바빈즈(Enterprise JavaBeans; EJB)는 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다. 즉, EJB는 애플리케이션의 업무 로직을 가지고 있는 서버 애플리케이션이다. EJB 사양은 Java EE의 자바 API 중 하나로, 주로 웹 시스템에서 JSP는 화면 로직을 처리하고, EJB는 업무 로직을 처리하는 역할을 한다.

EJB의 종류[편집]

EJB에는 다음 3가지 종류가 있다.
  • 세션 빈 (Session Bean) : DB 연동이 필요 없음
  • 엔티티 빈 (Entity Bean)
    • 데이터베이스의 데이터를 관리하는 객체
    • Insert(삽입), Update(수정), Delete(삭제), Select(조회)
    • DB 관련 쿼리는 자동으로 만들어지고 개발자는 고급 업무 처리에 집중할 수 있음
    • DB가 수정되면 코드 수정 없이 다시 배포(설정 문서 만들어서 복사)
  • 메시지 구동 빈 (Message-driven Bean) : JMS로 빈을 날려줌


EJB 배경, 설명(블로그 참조) 

http://pokey.tistory.com/7
>>>
EJB는 대규모 분산 객체 시스템을 구축하기 위한 기술 또는 자바로 서버 측 비즈니스 로직을 작성하기 위한 Enterprise 환경에서의 자바 표준이라고 보시면 됩니다. 흔히 프리젠테이션 로직이라고 하는 것이 화면에 보여지게 되는 정보의 타입, 포맷을 자동으로 처리하는 반면 비즈니스 로직은 급여계산 한다든지 하는 보이지 않는 어떤 처리를 하는 겁니다. 만약 EJB를 사용하기 위해 웹로직 서버를 이용한다고 하면 프로그램 개발자는 웹로직 서버의 컨테이너를 이용하여 작업을 하게 되는데 이는 트랜잭션의 지원, 보안, 동시 접근 처리 등 비즈니스 로직을 처리하는데 있어 필요한 모든 것을 제공 한다고 보면 됩니다.

참고
http://i-bada.blogspot.com/2014/09/enterprise-javabeanejb.html



********************************

빈(bean)

빈: 자바로 작성되어진 컴포넌트들로 JSP페이지에서 디자인부분과 로직부분을 분리시키고, 재사용성을 높여 효율성을 높여줌.

-규격
- 클래스는 패키지화 하여야 한다.
- 멤버변수는 프로퍼티(Property)라 칭한다.
- 클래스는 필요에 따라 직렬화가 가능하다.
- 프로퍼티의 접근자는 private이다.
- 프로퍼티마다 getter/setter 가 존재해야 하며, 그 이름은 각각 get/set으로 시작해야 한다.
- 위의 프로퍼티 getter/setter 메서드의 접근자는 public이어야 한다.
- 외부에서 프로퍼티에 접근은 메서드를 통해서 접근한다.
- 프로퍼티는 반드시 읽기/쓰기가 가능해야 하지만, 읽기 전용인 경우 getter만 정의할 수 있다.
- getter의 경우 파라미터가 존재하지 않아야 하고, setter의 경우 한 개 이상의 파라미터가 존재한다.
- 프로퍼티의 형이 boolean일 경우 get 메서드 대신 is메서드를 사용해도 된다.

참고




2018년 7월 29일 일요일

공통코드란? 코드 테이블 설계와 SQL 조회 예제

공통코드는 여러 화면과 테이블에서 사용하는 분류값을 코드와 표시 이름으로 나누어 관리하는 방법입니다. 예를 들어 게시판에는 B01을 저장하고, 화면에는 ‘일반게시판’을 표시합니다. 이 글에서는 게시판 종류와 회원 역할을 구분하는 작은 코드 테이블을 직접 만들어 봅니다.

2018년의 학습 메모를 2026년 10월 16일에 예제 중심으로 보완했습니다. 아래 구조는 설계 예시이며 모든 시스템에 적용해야 하는 표준은 아닙니다.

코드와 이름을 왜 나눌까?

게시글마다 ‘일반게시판’이라는 이름을 저장하면 명칭을 변경할 때 여러 데이터를 수정해야 할 수 있습니다. 코드와 이름을 분리하면 게시글의 분류값을 유지하면서 표시 이름을 관리할 수 있습니다. 다만 과거 화면의 명칭까지 보존해야 하는 서비스라면 별도의 이력 설계가 필요합니다.

그룹도 구분합니다. BOARD_TYPE은 게시판 종류, USER_ROLE은 회원 역할입니다. 코드만으로 찾지 않고 그룹과 코드를 함께 사용하면 서로 다른 분류의 값이 섞이는 실수를 줄일 수 있습니다.

테이블을 만들고 게시판 종류 조회하기

아래 예제는 빈 테스트 데이터베이스에서 실행하세요. Python의 SQLite 메모리 데이터베이스에서 생성·조회 및 중복 키 거부를 확인했습니다. MySQL·Oracle 실서버에서 실행한 결과는 아닙니다.

CREATE TABLE common_code (
    code_group VARCHAR(30) NOT NULL,
    code VARCHAR(20) NOT NULL,
    code_name VARCHAR(100) NOT NULL,
    sort_order INTEGER NOT NULL,
    active CHAR(1) NOT NULL,
    PRIMARY KEY (code_group, code)
);
INSERT INTO common_code VALUES
('BOARD_TYPE', 'B01', '일반게시판', 1, 'Y'),
('BOARD_TYPE', 'B02', '질문게시판', 2, 'Y'),
('BOARD_TYPE', 'B03', '사진게시판', 3, 'Y'),
('USER_ROLE', 'U01', '일반회원', 1, 'Y'),
('USER_ROLE', 'U09', '관리자', 2, 'Y');
SELECT code, code_name
FROM common_code
WHERE code_group = 'BOARD_TYPE' AND active = 'Y'
ORDER BY sort_order, code;

조회 결과:

B01 | 일반게시판
B02 | 질문게시판
B03 | 사진게시판

복합 기본 키는 같은 그룹 안의 코드 중복을 막습니다. sort_order는 화면 정렬 순서, active는 신규 선택 가능 여부를 표현하는 예시입니다. 이 테이블을 만든 것만으로 다른 업무 테이블의 코드값까지 검증되지는 않습니다. 참조 관계와 그룹 제약을 별도로 설계해야 합니다.

운영 전에 정할 네 가지 규칙

  1. 의미가 바뀌면 코드를 재사용하지 않기. 기존 데이터의 해석이 달라지지 않도록 새 코드를 검토합니다.
  2. 사용 중인 코드는 삭제보다 비활성화 검토. 신규 입력에서 숨겨도 과거 데이터의 이름은 조회할 수 있어야 합니다.
  3. 수정 권한과 변경 기록 정하기. 누가 이름·순서·활성 상태를 바꿨는지 추적합니다.
  4. 캐시 갱신 시점 정하기. 관리 화면에서 고친 이름이 서비스에 언제 반영될지 명확히 합니다.

회원 역할 코드를 저장하는 것과 접근 권한을 검사하는 것은 별개입니다. 클라이언트가 보낸 U09 값을 믿고 관리자 권한을 부여하면 안 됩니다.

공통코드 테이블과 enum 중 무엇을 쓸까?

배포 없이 운영자가 표시 이름이나 선택 항목을 관리해야 한다면 코드 테이블을 고려할 수 있습니다. 값이 프로그램의 분기와 강하게 연결되고 코드 변경과 함께 검토되어야 한다면 enum이 더 단순할 수 있습니다. 모든 상태값을 한 테이블에 몰아넣기보다 변경 주체와 참조 규칙을 먼저 정하는 편이 좋습니다.

2018년 7월 8일 일요일

Cot_pr1 개선하기 (진행 중) - LastUpdated 10/02

포트폴리오용 커뮤니티 웹페이지를 개선시키려고한다.
전에 존재하던 저장소가 gitignore 설정테스트하다가 커밋들이 꼬여서 너무 더러워졌다..
소스트리 사용해서 편하게 하려다가 망함 ㅠㅠㅠ

>>새로 프로젝트 생성해서 처음부터 ignore, branch 등 설정 제대로 해서 만들어보기!
-- 7/8 생성 완료


1. 오류페이지 생성 --- 7/15 완료
(403, 404, 405, 500에러시 이동하는 페이지 생성
web.xml에
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
  <!-- 에러 페이지 -->
  <error-page>
      <error-code>403</error-code>
      <location>/error/403</location>
  </error-page>
  <error-page>
      <error-code>404</error-code>
      <location>/error/404</location>
  </error-page>
    <error-page>
      <error-code>405</error-code>
      <location>/error/405</location>
  </error-page>
  <error-page>
      <error-code>500</error-code>
      <location>/error/500</location>
  </error-page>
cs
형태로 설정하여 에러코드 발생 시 error 컨트롤러로 이동하게 수정

403 - 권한 부족
404 - 페이지를 찾을 수 없음
405 - 잘못된 요청방식
(예를 들어 POST 방식으로 요청을 받는 서버에 GET 요청을 보내는 경우, 또는 읽기 전용 리소스에 PUT 요청을 보내는 경우)
500 - 서버 에러
)

2. 회원가입/ 로그인(연동추가) ++ 회원 전체적인 부분 다시 개선(회원정보,권한,로그인유지 등)

3. 도메인

4. ajax부분 다시 

5. xss필터

6. 공통코드로 관리할 것(권한, 게시판구분 등 ) ---  8/12 진행 중
----------7/29
-code테이블 생성
게시물, 회원코드로 관리할 것
(공통 코드란??)

코드로 관리하여 게시판 및 컨트롤러 통합해도 될듯

++++++8/12
현재형태: 각 게시판마다 글쓰기, 수정, 뷰, 댓글, 등 다 따로 있음.
일단 기존 것 그대로 나두고, 새로운 틀 생성해서 진행하기
>>
테이블들 코드로 관리하고, 게시판형태 하나로 통합해서 body만 각 게시판에
맞게 바꾸기 + 게시물 리스트, 페이징 처리할 때 ajax 써보기
>>NoN빨리 마무리하고 진행하기


7. service / dao / controller 수정(인터페이스만들기)


8. 스프링시큐리티 수정
(++관리자 로그인 후 관리자 페이지 이동 시 비밀번호 입력(의미없음 - 수정 필요)



9. 로그출력 추가 --- 10/02 완료
logback 으로 간단한 로그 남기는 것  추가함.
(로그 남기기)



10. 트랜잭션 설정하기



11. +++계속 추가

(NoN 플젝에 엑셀파일 읽는 것을 스케줄러로 처리하면좋을듯?) 

2018년 7월 1일 일요일

리눅스 기본 명령어

cp file1 file2 : 파일1을 파일2로 복사하기

ls : 디렉토리와 파일정보 표시
<옵션>
    -l 파일에 대한 정보(파일 허용권, 소유자, 그룹, 크기, 날짜)를 긴 형식으로 보여줍니다.
    -a 는 모든 파일을 지정합니다(디렉토리의 히든 파일도 보여줍니다).
    -i 파일의 'inode'도 같이 보여줍니다.
    -t 최종 수정된 시간별로 정렬합니다.
    -r 파일을 역순, 즉 내림차순으로 배열합니다.
    -u 변경되지 않았더라도 최근에 엑세스했던 파일들을 보여준다. 이 t나 u옵션으로 최근          에 다루었던 파일을 찾는데 유용하게 쓸 수 있습니다.
    -F 파일의 특성을 보여줍니다. 이름 뒤에 디렉토리면 /를 실행파일이면 *, 심블릭 링크된           파일이면 @를 붙여줍니다.
    -R 하위 디렉토리의 파일도 모두 보여줍니다.
    -C 컬럼별로 파일을 보여줍니다.
    -w 컬럼수로 가로의 크기를 설정합니다.
    -m 가로로 간단히 출력합니다.
    -- color=yes 서브디렉토리를 구별하기 위해 color로 보여집니다.
    
리눅스의 명령어에서 이런 옵션들은 대개 여러 개를 같이 써 줄 수 있다.    
ex) -a -l은 -al과 같이 쓸 수 있습니다..
      ls -art는 현재 디렉토리에서 파일이 최종 수정된 시간의 내림차순으로 정렬된 모든 파일의 이름을 나열합니다. 따라서 가장 최근파일이 맨 아래에 표시됩니다.






cd :디렉토리를 변경


 cd ABC    : 하부 디렉토리인 ABC으로 들어감.
 cd  ..             : 상위디렉토리로 이동
 cd 또는 cd ~  : 어느곳에서든지 자기 홈디렉토리로 바로 이동
 cd /webker     : 현재 작업중인 디렉토리의 하위나 상위 디렉토리가
                          아닌 다른 디렉토리(webker)로 이동하려면 /로
                          시작해서 경로이름을 입력하면 된다.








http://nuninaya.tistory.com/158


https://www.mireene.com/webimg/linux_tip1.htm