문제 상황
현재 프로젝트를 윈도우와 리눅스 컨테이너 양쪽에서 작업을 진행하던 중, github 토큰을 등록을 하게 되었다. 깃허브 홈페이지에서 성공적으로 토큰을 발급받고, 이를 활용하여 비밀번호를 입력한 후 성공적으로 push를 할 수 있게 되었다. 문제는 이후의 push 에서도 계속해서 비밀번호를 요구한다는 점이였다. 환경이 조금 특이해서 (도커 컨테이너 ubuntu, wsl) 다양한 방법을 시도해봤는데, 시간을 예상보다 많이 쏟게 되어 기록을 위해 글을 작성한다.
Linux 환경
방법 0
git config --global credential.helper store
보안적으로 추천하지 않는 방법이다. git이 설치된 위치에서 git-core를 들어가면, git-credential-store라는 파일이 있는데, 거기에 토큰을 기록하는 방식이다. 사실 가장 편하긴 한데, 역시 보안적으로 취약하다는 점에서 권장되는 방식은 아니다.
방법 1
sudo apt-get install libsecret-1-0 libsecret-1-dev
cd /usr/share/doc/git/contrib/credential/libsecret
sudo make
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret
원리는 libsecret이라는 패키지를 설치하여, 해당 패키지에 token을 저장하고 token이 필요한 경우 github는 명시한 credential.helper인 libsecret을 참고하여 인증을 수행한다.
여기까지해서 문제가 없으면 다행인데, 현재 docker 컨테이너 환경에서 작업을 진행하던 중 다음의 에러를 만날 수 있었다.
** (process:23898): CRITICAL **: 12:21:26.791: store failed: Cannot autolaunch D-Bus without X11 $DISPLAY
그래서 위의 방법이 안된다면 다른 방법을 시도해봐야 한다.
방법 2
그래서 어떻게 해결할 것이냐. git-credential-manger를 통해 토큰을 관리할 것이다.
가장 먼저 다음의 명령어로 수행이 가능하다면, 쉽게 갈 수 있다. git-credential-manager가 이미 설치된 경우이다.
git config --global credential.helper manager-core
근데, 내 컨테이너 환경에는 무슨 일이 일어났던 건지, 정상적인 git 경로에 credential-manager가 존재하지 않았다.
/usr/lib/git-core# ls git-credential*
git-credential git-credential-cache git-credential-cache--daemon git-credential-store
그래서 직접 설치해주었다.
먼저 방법 1을 수행하지 않았다면 필요한 패키지를 설치해준다.
sudo apt-get install libsecret-1-dev
다음으로 credential-manager의 패키지 파일을 다운로드하고
(여기가 조금 오래 걸린다. 서버가 빠르지 않다... 최신 버전의 릴리즈는 더 느리다...)
wget https://github.com/microsoft/Git-Credential-Manager-Core/releases/download/v2.0.498/gcmcore-linux_amd64.2.0.498.54650.deb
패키지를 설치해준다.
sudo dpkg -i gcmcore-linux_amd64.2.0.498.54650.deb
여기까지 왔다면 설치는 완료되었고, 잘 설치되었나 확인 한번 해주자.
git credential-manager version
마지막으로 git에 설치한 credential-manager를 사용한다고 등록해주면 끝난다.
git config --global credential.helper manager-core
이후 push 수행 시 문제 없이 업로드가 가능해진다.
wsl, debian
방법 0
git config --global credential.helper store
보안적으로 취약하기에 권장되는 방식은 아니다. (위의 linux 부분을 참고)
방법 1
앞의 방법으로 credential.helper를 활용하면, 다음과 같은 에러 메세지를 만날 수 있다.
could not connect to Secret Service: Cannot autolaunch D-Bus without X11 $DISPLAY
위의 credential-manager를 설치해서 해결을 할 수도 있지만, 좀 더 쉬운 방법이 있다.
바로 윈도우 쪽에 설치된 git에서 자체적으로 제공하는 credential-manager의 경로를 직접 먹여주는 것이다.
git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/libexec/git-core/git-credential-wincred.exe"
문제가 없다면 해당 명령 수행 이후 정상적으로 push가 추가적인 비밀번호 없이도 가능해진다.
만약 잘 안된다면 해당 경로에 git-credential-wincred.exe가 실제로 있는지 확인하고, 만약 없다면 직접 설치 이후, 설치된 위치의 credential-manager를 활용하는 방식으로 해결이 가능할 것 같다.
'etc > errors' 카테고리의 다른 글
| 스크립트를 통한 ssh 접속 (0) | 2023.04.07 |
|---|---|
| SSH를 통한 Root 로그인 불가 시 해결 방법 (0) | 2023.04.07 |
| Git 충돌날 때 사용가능한 간단한 대처방법 (0) | 2023.03.26 |
| [VirtualBox, Window] 호스트 전용 네트워크 설정 오류 "Querying NetCfgInstanceId failed (0x00000002)." (0) | 2022.11.22 |
ssh를 접속하는 가장 기본적인 방법은 bash의 ssh 명령어를 사용하는 것이다.
기본적인 사용방법은 다음과 같이 직관적이다.
ssh <ip-address>다만, 앞선 명령어는 현재 로컬 머신의 ip 주소를 그대로 가지고 서버에 접속을 시도하기 때문에, 해당 의도가 아닌 경우라면 비밀번호와 유저가 일치하지 않아 로그인이 안되는 문제가 있다.
ssh <username>@<ip-address>때문에 주로 위의 명령어처럼 유저를 명시하고 사용을 권장하곤 한다.
이는 argument로도 전달이 가능한데, 바로 -l 옵션을 통해서이다.
ssh -l <username> <ip-address>
여기까지가 기본적인 명령어 사용방법이였다.
ssh 명령어가 있으니 이를 활용하여 ssh 접속을 스크립트 실행을 통해 간소화해보고 싶었다.
문제는 비밀번호를 넣는 부분인데, ssh 명령어를 통해서는 비밀번호를 스크립트로 넣을 수가 없었다.
-p 옵션이 있기 때문에, 될 것 같은 느낌도 들지만 해당 옵션은 포트를 명시하는 옵션이다.
때문에, 비밀번호를 가지고 ssh 접속을 하기 위해서는 sshpass 라는 패키지를 설치해줘야 한다.
# Ubuntu or Debian
sudo apt-get install sshpass
# macOS
brew install http://git.io/sshpass.rb이후 다음 명령어를 통해 비밀번호를 스크립트 안에 밀어넣을 수 있다.
sshpass -p <password> ssh -l <username> <ip-address>
ssh가 보안 상의 이유로 비밀번호를 노출시키지 못하도록 한 것을 sshpass가 끄집어냈다는 느낌이 든다. 사실 근데 대부분의 상황에서 편리하자고 sshpass를 쓰는게 맞을까 하는 의문은 든다. 혹여나 스크립트가 노출이 되어버리면 곧바로 컴퓨터에 대한 모든 권한을 넘겨주는 것이기에, sshpass는 최대한 지양하는 것이 맞을 것 같다.
그럼에도 ssh를 자동으로 접속해야만 하는 불가피한 상황이 있을 수 있으니 해당 상황에서는 꼭 방화벽을 철처하게 설정해줘야 하지 싶다.
'etc > errors' 카테고리의 다른 글
| git push시 계속해서 인증을 요구하는 경우 (0) | 2023.04.09 |
|---|---|
| SSH를 통한 Root 로그인 불가 시 해결 방법 (0) | 2023.04.07 |
| Git 충돌날 때 사용가능한 간단한 대처방법 (0) | 2023.03.26 |
| [VirtualBox, Window] 호스트 전용 네트워크 설정 오류 "Querying NetCfgInstanceId failed (0x00000002)." (0) | 2022.11.22 |
접속하고자 하는 Server 터미널에서
sshd_config 파일을 열고
sudo nano /etc/ssh/sshd_config
해당 부분을 Yes로 바꿔준다.
PermitRootLogin Yes
이후 sshd 재시작 해주며 변경 사항 적용해주면 끝.
sudo systemctl restart sshd
(써놨으니 안까먹겠지...)
'etc > errors' 카테고리의 다른 글
| git push시 계속해서 인증을 요구하는 경우 (0) | 2023.04.09 |
|---|---|
| 스크립트를 통한 ssh 접속 (0) | 2023.04.07 |
| Git 충돌날 때 사용가능한 간단한 대처방법 (0) | 2023.03.26 |
| [VirtualBox, Window] 호스트 전용 네트워크 설정 오류 "Querying NetCfgInstanceId failed (0x00000002)." (0) | 2022.11.22 |
문제 상황
Local Repository (master)
- A.cpp
- B.cpp
- AA.H
Remote Repository (main)
- README.md
Remote Repository (master)
- A.cpp
- B.cpp
- AA.H상당히 이상한 예시지만, 실제로 위와 같은 상황에 대처해보는 방법을 전부터 작성해보고 싶어 이번 기회에 작성하고자 한다.
기존에는 그냥 간단하게 새로 clone 받아서 복구하는 형태로 충돌을 대처했다면, 만약 clone 외에 어떠한 방식으로 충돌을 해결할 수 있을 지를 남기고자 한다.
먼저, 문제 상황을 살펴보면 로컬/리모트 두 저장소가 서로 합쳐질 수 있는 듯 보이지만, master라는 어디선가 생겨버린 브랜치와 main 브랜치는 현재 아무런 접점이 없어, 히스토리를 서로 추적할 수 없는 상황이다.
그래서 우선적으로 local에 main 브랜치를 생성해주고 이동해주었다.
git branch main
git checkout main이후 동일하게 add, commit, push 를 진행해주었다.
git add .
git commit -m "my commit message"그럼에도 여전히 push 명령어는 오류를 발생시켰다.
git push origin main
To https://github.com/mukmookk/repo.git
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'https://github.com/mukmookk/repo.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.여전히 현재 로컬의 main 브랜치와 리모트 main 브랜치 간의 충돌이 발생함을 확인할 수 있다.
이는 로컬의 파일들과 리모트에 위치한 README.md 간의 히스토리가 일치하지 않기 때문일 것이다.
때문에 명령어의 힌트에 나온 것처럼 pull 명령어를 시도해보았다.
git pull origin main
From https://github.com/mukmookk/repo
* branch main -> FETCH_HEAD
fatal: refusing to merge unrelated histories그러나 별도의 옵션이 존재하지 않는 pull 명령어는 여전히 오류를 발생시켰고, 이는 push가 실패한 이유와 크게 다르지 않은 것으로 추정된다.
해결
다만, 히스토리가 다르더라도 병합될 브랜치 파일들 간에 간섭이 없는 위의 상황이라면 pull의 --allow-unrelated-histories 옵션이 해결책일 수 있다.
git pull origin main --allow-unrelated-histories
From https://github.com/mukmookk/repo
* branch main -> FETCH_HEAD
Merge made by the 'ort' strategy.
README.md | 1 +
1 file changed, 1 insertion(+)
create mode 100644 README.md위의 명령어는 서로 관련없는 히스토리를 가졌다고 해도, 두 브랜치 간의 머지를 허용해주는 옵션이다. 때문에 앞서 제시된 문제상황과 같은 경우에 해당 명령어를 작성해주면 다음과 같이 로컬 저장소에 머지가 된다.
Local Repository (master)
- A.cpp
- B.cpp
- AA.H
- README.md이를 다시 push 해주면 당초 목표했던 push가 가능해진다.
git push origin main
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 366 bytes | 366.00 KiB/s, done.
Total 2 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/mukmookk/repovvvvvvvv.git
7923c39..545efbd main -> main'etc > errors' 카테고리의 다른 글
| git push시 계속해서 인증을 요구하는 경우 (0) | 2023.04.09 |
|---|---|
| 스크립트를 통한 ssh 접속 (0) | 2023.04.07 |
| SSH를 통한 Root 로그인 불가 시 해결 방법 (0) | 2023.04.07 |
| [VirtualBox, Window] 호스트 전용 네트워크 설정 오류 "Querying NetCfgInstanceId failed (0x00000002)." (0) | 2022.11.22 |
가상현실(VR)
VR은 Virtual Reality의 약자로 가상현실이라고 한다. 우리가 살고 있는 물리적인 공간이 아닌 컴퓨터로 구현한 가상 환경 또는 그 기술 자체를 말한다. 사용자의 주변 환경을 차단해 새로운 세계로 들어간 것처럼 몰입감을 주는 것이 핵심이라서 머리에 쓴는 디스플레이 디바이스 HDM을 활용해 현실 세계와 차단하는 콘텐츠가 주를 이룬다. 일상생활은 물론 IT, 의료, 제조, 자동차, 음악, 쇼핑, 게임 분야 등 다양한 부문에서 기술적인 성장을 이어나가고 있다.
증강현실(AR)
AR은 Augumented Reality의 약자로 증강현실이라고 한다. VR과 달리 위치, 지리정보를 송수신하는 GPS 장치 및 중력 그리고 자이로스코프에 따른 위치정보 시스템을 기반으로 우리가 경험하는 현실 세계에 가상의 물체나 정보가 합성되어 실제 현실을 가상현실과 상호작용이 이뤄지는 공간으로 만들어주는 기술이다. 사용자가 보고 있는 실사 영상에 3차원 가상 영상을 중첩함으로써 현실과 가상의 구분이 모호한 것이 특징이다. 최근에는 산업용 증강현실이라는 이름으로 제조, 유통, 의료현장 등에서도 많이 활용되고 있고 앞서 얘기한 포켓몬 게임이나 구글 글라스가 대표적이다. 증강현실을 적용한 네비게이션의 경우 실제 도로장면에 주행 정보를 추가해서 보여주기도 하고, 의류 매장에서 직접 옷을 입어보지 않고도 화면 상에서는 입은 것 같은 시스템을 구현해준다. 또한 스마트폰 앱으로 많이 사용하고 있는 스노우는 증강현실 기술을 활용한 대표적인 카메라 앱이다.
혼합현실(MR)
MR은 VR이나 AR보다 한 단계 더 나아간 기술인데 Mixed Reality의 약자로 혼합현실을 말한다. VR과 AR 두 기술의 장점만을 합친 기술로 MR은 현실과 가상의 정보를 융합해 조금 더 진화된 가상세계를 구현하고 냄새 정보와 소리 정보를 융합하여 사용자가 상호작용할 수 있는 기술을 말한다. VR과 AR은 시각에 전적으로 의존하지만 MR은 시각 외에 청각, 촉각 등 인간의 오감을 접목시킬 수 있다는 점이 다르다.
마이크로소프트에서 나온 홀로랜즈는 자신이 위치한 현재의 공간을 3차원 스캔할 수 있고 스마트폰이나 PC와 연결할 필요없이 단독 구동이 가능하다. 홀로랜즈를 착용하면 먼 거리에 떨어져있는 사람과도 한 자리에 있는 것처럼 자연스럽게 회의를 진행할 수 있다. 현재 MR 기술은 사람의 귀가 아닌 다른 방법을 통해 소리를 전달하는 기술도 개발되고 있으며 촉각을 활용한 햅틱과 팁톡의 기술도 나오고 있다. 국내의 경우 SK 텔레콤이 혼합현실 제작소 점프 스튜디오를 가동, 온라인 라이브 공연에 처음으로 활용하기도 했다.
확장현실(XR)
ER 혹은 XR이라고도 불리는 확장현실은 Extended Reality의 약자로 컴퓨터 기술로 인한 현실-가상 세계의 결합과 인간-기계의 상호 작용을 말한다. 가상현실과 증강현실, 혼합현실을 포괄적으로 XR이라고도 한다. XR은 MR에서 확장된 개념으로 볼 수도 있다. 현실과 가상 간의 상호 작용을 강화해 현실 공간에 배치된 가상의 물체를 손으로 만질 수 있다. 코로나19와 같은 상황 하에 글로벌 원격 회의를 할 때 각 국가나 회사 출근 여부에 상관없이 XR은 하나의 디지털 공간에 자료를 띄워서 공유할 수 있다. 따라서 XR은 위험에 빠질 수 있는 상황이나 재료의 낭비없이 교육이나 훈련을 시뮬레이션으로 할 수 있는 의료, 제조 및 군사산업 등에서 활용할 수 있다.
'etc' 카테고리의 다른 글
| Digital Twin (디지털 트윈) (0) | 2022.11.29 |
|---|
디지털 세계와 물리적 제품 사이의 경계가 모호해짐에 다라 4차 산업 혁명의 최전선에서는 빅데이터, 머신러닝, 가상 현실과 같은 "스마트" 기술 애플리케이션이 등장하였다. 일반적으로 디지털 트윈은 물리적 자산, 시스템 또는 프로세스를 소프트웨어로 표현하는 것을 의미하며, 실시간 분석을 통해 대상을 감지 예방, 예측 및 최적화하여 비즈니스 가치를 제공하는 역할을 수행한다. 즉 가상의 공간에 '진짜 세상'의 복제를 만드는 것을 의미한다.
Digital Twin의 예시 ( 항공기 제작 및 정비)
실제 항공기에서는 실제 제품 환경 및 작동 조건의 다양한 측면을 모니터링하는 센서의 데이터를 사용하여 지속적으로 학습하고 업데이트되며, 이전에 담아두었던 데이터를 활용하여 실제 물리적인 요소의 개선을 이뤄낸다.
만약 엔지니어링 측면에서 Digital Twins를 사용하면 확률 기반 기술에 의존하여 엔진 유지 보수 또는 수리가 필요한 시기를 결정할 필요성이 줄어들게 된다. 대신 앞서 소개한 다양한 4차 산업 기술을 활용하여 디지털 트윈의 개념을 도입, 실제 제품의 정확한 가상 사본인 엔진의 디지털 트윈을 생성하게 된다면 실제 엔진이 날개를 펼침과 동시에 가상 세계에서도 이를 인지하고 엔진 작동 방식을 결정하게 된다. 또한 데이터를 활용하게 되어 유지보수가 필요한 시기를 미리 예측할 수 있게되어 예방적인 엔진 유지 보수를 할 수 있ㄷ어 항공기의 가동 중지 시간을 크게 줄이고 항공기 운항 측면에서의 안정성을 높일 수 있게 된다.
또한 항공기 부품에 대한 이해와 조작에 대해서도 디지털 트윈을 활용한다면 훨씬 고수준의 접근이 가능하다. 항공정비를 배우는 학생에게는 이러한 디지털 트윈은 본인 기술을 향상시킬 수 있는 기회로 작용한다. 실제 비행기 모델을 통해 학습을 진행할 수도 있지만, 이는 비용이 많이 들 뿐만 아니라 실제 코어한 부분까지 알기는 쉽지 않다. 물론 부분부분 각 요소가 어떻게 생겼는지는 구경할 수 있을지는 모르지만 전체적으로 어떤 구조로 이뤄져있는지 이해하는 것은 기존 교육만으로는 한계가 있다. 디지털 트윈은 항공기 내부를 그대로 디지털 세계로 옮겨 물리적인 한계를 넘어서게 할 수 있다. 교육생들은 디양한 조작법을 활용하여 실제 사이즈의 비행기를 가상 환경을 통해 접할 수 있을 것이다.
실제 정비 또한 디지털 트윈에서 사용하는 데이터 분석을 활용하여 물리적 엔진 테스트가 허용하는 것보다 더 많은 잠재적 시나리오를 모델링할 수 있으므로 더 많은 이해가 가능해진다.
'etc' 카테고리의 다른 글
| VR의 발전과 분류 (0) | 2022.11.29 |
|---|
[VirtualBox, Window] 호스트 전용 네트워크 설정 오류 "Querying NetCfgInstanceId failed (0x00000002)."
문제 상황
Virtual Box를 통해 호스트 전용 네트워크를 설정하고자 함. 만들기 버튼을 눌렀더니, creating host only network interface not working 라는 메세지가 꽤나 오랜시간 뜨더니 생성이 실패함.
버전을 변경해가며 재설치를 진행했고, 혹시나 제거가 완벽하게 되지 않아서 생긴 문제인가 싶어서 로그 파일까지 다 지웠음에도 문제가 해결되지 않았음.
로그: creating host only network interface not working
문제 해결
Summary: 이더넷 네트워크 설정에서 VirtualBox NDIS6 Bridged Networking Driver를 제거.
Step 1: 현재 실행 중인 Virtual Box를 종료
...
Step 2: 기존에 사용하던 Virtual Box를 제거
Step 3: 설정 > 네트워크 및 인터넷 > 어뎁터 옵션 변경 으로 이동
Step 4: 마우스 우클릭 후 속성으로 진입, VirtualBox NDIS6 Bridged Networking Driver를 제거
(Virtual Box가 제거되지 않은 경우 해당 항목의 삭제가 정상적으로 되지 않음)
Step 5: Virtual Box 재설치
원하는 버전으로 재설치
Step 6: 별도의 작업 없이도 VirtualBox Host-Only Ethernet Adaptor가 정상적으로 추가되었다면 성공
Virtual Box 내부에서도 확인 가능
'etc > errors' 카테고리의 다른 글
| git push시 계속해서 인증을 요구하는 경우 (0) | 2023.04.09 |
|---|---|
| 스크립트를 통한 ssh 접속 (0) | 2023.04.07 |
| SSH를 통한 Root 로그인 불가 시 해결 방법 (0) | 2023.04.07 |
| Git 충돌날 때 사용가능한 간단한 대처방법 (0) | 2023.03.26 |