꿜리의 블로그

터미널로 작업하다가 파일 및 디렉토리 퍼미션 속성을 보다가 @(골뱅이)가 보여서 '엉? 이게 뭐지' 했다.

그래서, 검색해봤더니 역시나 궁금해하는 녀석들이 있다.

https://unix.stackexchange.com/questions/92071/file-permissions-mode-ending-in-or

추가적인 ACLs 속성이 있다고... 'xattr -l <파일명>' 으로 속성 값을 확인해볼 수 있다.

https://www.howtogeek.com/444596/how-to-change-the-default-shell-to-bash-in-macos-catalina/

카탈리나부터 기본이 zsh로 변경되어서 bash를 사용하려면 전환을 해야한다. 레거시로 최신 버전 쓰려면 홈브류나 맥포트에서 업데이트도 해줘야 하는 듯.

케플러 및 루나 버전의 이클립스를 high sierra에서 실행하기 위해서 노력해보았지만 잘 되지 않았다.

실행 시 자바 관련 이슈가 나와서 일단은 레거시 버전들을 1.6부터 설치한 뒤 bash_profile에서 JAVA_HOME을 설정해주었지만 이것 역시 정상적으로 실행되지 않았다.

음...프로젝트를 빌드하기 위해서는 특정 제품의 플러그인 설치가 필요한데, Oxygen이나 Proton에서는 플러그인이 작동하지 않기 때문에 케플러나 루나가 필요한 상황이다.

일단 검색의 결과는 자바 버전 관련된 이슈가 맞는데, JAVA_HOME을 bash_profile이나 jenv로 변경을 해도 시스템에서 참조하는 자바 실행환경은 항상 jdk 9으로 고정이 되어 있다.

결국은 이슈가 해결되지 않아서 ' /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents' 내의 info.plist 파일을 다른 파일명으로 변경했다.

그랬더니 차상위의 JAVA 버전이 시스템에서 참조하는 자바 실행환경으로 자동적으로 설정이 되었다. 흠...

실제 자바 VM의 실행환경은 '/usr/libexec/java_home' 명령어로 확인이 가능한데, 컴파일러의 경로와는 다르게 참조를 하고 있는 것으로 보인다.

아무튼 옥시겐 이전 버전의 이클립스 실행 문제는 자바 9으로 설정된 실행환경문제로 이 옛날 버전의 이클립스를 사용해야만 하는 환경이라면 이와 같이 설정을 꼼수로 변경하는 수 밖에 없는 것 같다.

맥프로에서 빌드된 다른 앱 소스를 좀 읽어보려고, JD-GUI 홈(http://jd.benow.ca/)에서 맥용 파일을 다운받아서 실행해보니 이상하게 실행이 안된다.

검색을 좀 해보니 자신의 맥북 환경에 맞게 설정을 수정할 필요가 있어 보여서 일단 깃헙의 이슈 트랙커의 글을 참고하여 깃에 있는 소스를 새로 빌드해서 설정을 변경해주었다.

아래와 같이 깃허브 레퍼지토리에서 클론을 하거나 다운로드하여 빌드를 진행했다.

$ git clone git@github.com:java-decompiler/jd-gui.git

$ cd jd-gui

$ ./gradlew installOsxDist

$ cd build/install/jd-gui-osx

[출처: https://github.com/java-decompiler/jd-gui/issues/189 ]

위에서 처럼 타겟을 OS X 기반으로 그래들 빌드 후에 생성된 빌드 폴더 내에 실행 바이너리가 생성이 된다.

바로 실행해봤는데 그래도 정상적으로 실행이 안된다.

위에 있는 출처의 이슈를 더 읽어보니 맥에 설치된 자바의 경로를 지정해줄 필요가 있어 보인다.

$ java -version

$ /usr/libexec/java_home -v 1.8

자바의 버전을 확인해보니 1.8이어서 두 번째 줄과 같이 해당 자바의 설치 경로를 확인한 뒤 경로를 복사했다.

JD.GUI 앱을 선택하고, 마우스 우클릭을 통해서 '패키지 내용보기' 선택 후 아래의 파일을 편집기로 연다.

Contents/MacOS/universalJavaApplicationStub.sh

universalJavaApplicationStub.sh 파일을 편집기로 연 뒤에는 아래의 내용과 같이 JDK 설치 경로를 추가해주면 된다. (아래는 나의 경우)

JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home

다시 앱을 실행시키니 정상적으로 실행이 되었다.

생각해보니 따로 빌드할 필요 없이 그냥 맥 버전을 다운로드 받아서 위와 같이 경로만 추가해줘도 잘 실행될 것 같다.

흠...

엇?

분할압축을 해보려고 하니 기본 압축으로는 분할 압축이 안된다.

그럼, 반디집 써야지 하고 확인해보니 bandizip X 프로그램으로는 압축이 안된다.

확인해보니 반디집에서 압축프로그램을 작년에 맥 앱스토어에서 판매하기 시작했다.

https://itunes.apple.com/kr/app/id1265704574

반디집은 꽤나 괜찮은 압축프로그램이므로 하나 사줘도 무방하기는 한데, 무료 앱이 없을까 찾아봤다.

블로그들에서 권장하는 프로그램은 keka라는 프로그램이 있어서 다시 맥 앱스토어에서 검색해보니 이것도 유료.

분할 압축을 지원하는 프로그램들은 대부분 유료 프로그램이고, 미리 써보기 등이 쉽지 않아 보여서 다시 검색 시작.

7z 사이트에 가서 맥용 프로그램 없는 지 확인해보니 keka의 무료 버전이 있다.

맥 앱스토어에서 판매하는 유료 버전과의 차이점은 잘 모르겠는데, 일단 무료 버전이 있어서 다운로드 후 분할 압축을 해본다.

속도가 좀 느리다.

윈도우에서 멀티코어 지원하는 압축 프로그램과 비교하다보니 느린 속도가 바로 느껴졌다.

그래도 원만한 포맷으로 .DS_STORE 파일도 안만들고 분할 압축 및 압축 해제가 가능하니 간단하게는 쓸만하다는 생각이다.

아래의 링크에서 keka를 찾아서 다운로드 후 설치하면 된다.

http://www.7-zip.org/download.html

*. 4기가 분할 압축으로 사용해보니 성능이 생각보다는 좋지 않았다. 반디집을 사용해보면 아마도 비교가 가능하기는 할텐데, 가볍게 사용하는 경우에는 문제가 없지만 60기가 정도를 분할 압축하니 시간도 많이 걸리고 에러도 있었음.

https://support.apple.com/en-us/HT204063

블루투스 이슈가 있어서 라이브러리 폴더의 설정 파일 하나를 삭제했더니 갑자기 와이파이 자체에 x표시가 뜨면서 '설치된 하드웨어가 없다'고 표시된다.

검색해보니 NVRAM을 초기화하는 방법을 통해서 설정을 다시 잡는 것 같다.

확인 방법은 다음과 같다.

1. 맥을 완전히 끈다.

2. 다시 부팅하여 하얀 화면이 되면서 '텅~'하는 부팅음이 들릴 때 <alt + command + P + R > 버튼을 동시에 눌러준다.

3. 다시 '텅~'하는 부팅음이 조금 크게 들리면 누르고 있던 버튼을 모두 떼어 준다.

4. 프로그레시브 바가 진행되면서 부팅이 되면 정상으로 설정이 돌아온다.

사파리에서 PDF 링크가 있는 경우 바로 다운로드가 안되고 바로 파일을 브라우저에서 여는 경우가 많다.

가끔 골치아팠는데, 해결책이 여기 있네.

http://apple.stackexchange.com/questions/57039/how-make-safari-download-pdf-files-instead-of-opening-them-in-page

바로 다운로드 받게 하고 싶을 때

defaults write com.apple.Safari WebKitOmitPDFSupport -bool YES

다운로드 후 실행되지 않도록 하고 싶을 때

defaults write com.apple.Safari AutoOpenSafeDownloads -bool NO

다시 되돌리고 싶을 때는 옵션을 다시 변경한 뒤 사파리를 재실행하면 된다.

맥에서 이슈는 엘 캐피탄까지 된다는 이야기가 있다. 시에라에는 적용이 안되는 듯...

공인인증서의 개인키를 읽어보려고 했는데, 생각처럼 되지 않았다.

(Seed 방식의 블록 암호화인데...openssl 명령어로는 그냥 읽을 수가 없어서...흠)

우선 PEAR 설치 후 phpseclib를 다운받아서 실행해보았다.

1) PEAR 설치 - https://jason.pureconcepts.net/2012/10/install-pear-pecl-mac-os-x/

2) phpseclib - http://phpseclib.sourceforge.net

로컬 서버에 설정을 해서 실행해보니 생각처럼 값을 손쉽게 읽어오지는 못했다.

아마도 공인인증서의 키 암호화 방식이 일반적인 방식과는 다르게 구현이 된 것으로 보인다.

아무튼, 조금 찾아보다보니 Bouncy Castle Crypto APIs(http://www.bouncycastle.org/)라는 것이 있다는 것을 알게 되었다.

1) 설치방법 - http://www.bouncycastle.org/wiki/display/JA1/Provider+Installation

2) maven repository

 - http://repo2.maven.org/maven2/org/bouncycastle/bcpkix-jdk15on/

- https://mvnrepository.com/artifact/org.bouncycastle/bcprov-jdk15on/1.55  (실제 나중에 적용은 1.52로 변경하였다.)

파일을 다운로드 후 jar 파일들을 다음의 폴더로 옮겨주었다.

다음은 내 맥의 설정에 따른다.

/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/lib/ext

파일을 모두 옮긴 뒤에 java.security 에 선언되어 있는 security 패키지를 Bouncy Castle Crypto로 변경해준다.

/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/lib/security

내에 있는 java.security 파일에서 다음의 항목을 수정

security.provider.11=org.bouncycastle.jce.provider.BouncyCastleProvider

근데, 다음과 같이 에러가 뜬다...훔

Exception in thread "main" java.lang.SecurityException: JCE cannot authenticate the provider BC

at javax.crypto.Cipher.getInstance(Cipher.java:642)

at CertificateTest.getPrivateKey(CertificateTest.java:129)

at CertificateTest.main(CertificateTest.java:31)

Caused by: java.util.jar.JarException: file:/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/lib/ext/bcprov-jdk15on-155.jar has unsigned entries - org/bouncycastle/LICENSE.class

at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:462)

at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:322)

at javax.crypto.JarVerifier.verify(JarVerifier.java:250)

at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:161)

at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:187)

at javax.crypto.Cipher.getInstance(Cipher.java:638)

... 2 more

아래 내용으로 해봤는데, 잘 안된다...함 더 알아봐야 할 듯.

http://stackoverflow.com/questions/16469567/securityexception-with-bouncy-castle

이슈를 해결해기 위해서 해본 작업들이다.

1) 로컬 프로젝트의 libs 폴더 생성 후 프로젝트에 추가

2) jre의 ext 폴더에 담은 후 java.security의 수정

3) 2번의 작업 후 build path에서 jre 삭제 후 다시 add library를 선택하여 다시 system jre를 추가

찾아 헤매다가 결국은 해결을 했는데, 155 버전이 아닌 152 버전으로 변경 후 인증 관련 이슈가 모두 사라졌다.

으앙~

맥에서 백그라운드로 실행되는 데몬과 에이전트를 lauchd 라는 launchctl 제품이 있다고 한다.

아무튼 기본 사용법은 간단하다.

FTP 서비스 시작 >

sudo -s launchctl load -w /System/Library/LaunchDaemons/ftp.plist

FTP 서비스 종료 > 

sudo -s launchctl unload -w /System/Library/LaunchDaemons/ftp.plist

이렇게 시작하면 일단 사용자 계정의 루트로 접근하므로, 실제로 사용하려면 몇 가지 설정을 선택하여야 할 것 같다.

우선 테스트를 위해서 한 번 실행해봄.

출   처 - http://igerry.com/desktop/apple-os/enabling-ftp-server-os-x-mavericks.html

사용법 - https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/launchctl.1.html