11월 7일 우연히 '오블완 챌린지' 를 보고, 심심한데 1등이나 노려볼까? 하는 생각으로 열심히 비공개를 풀었는데, 정신 차려보니 11월 15일이네 ㅋㅋ 욕심 좀 부려서 1등 상품인 아이폰16 Pro 한번 노려 보려고 했는데...

비공개한게 8개월 정도는 됐으려나... 양질은 아니지만서도 조금이나마 광고비 좀 받아볼까 했더니만, 뭔 자동클릭을 감지했다나 말 같지도 않은 태클들로 짜증나게 해서 커스텀 다 빼버리고 적당한 블로그로 다시 갈아타보려고 했는데 참 쓸만한 블로그 찾기 힘들었었지. 얘는 이게 아쉽고, 쟤는 저게 아쉽고, 그래서 그냥 답답한 마음에 닫았었던가... 근데 다시 그대로 열었네ㅋ 내가 왜 그랬을까.. 이런 말도 안되는 이벤트로 다시 일상을 쓰게 됐다는게 좀 어이없긴 한데...

요즘 내 일과이자 내 삶. 매일 야근에 집에 도착하자마자 출근 준비 해놓고 잠자기 바쁘고, 술만 안먹으면 아침 운동가서 온 에너지 불태우고, 회사에서는 또 정신없이 하루가 다 지나가고. 이 세상이 어떻게 돌아가는지 화장실에서나 자기 직전에 헤드라인 한번 훑어보고. 가끔씩 술 땡길 때 일찍 퇴근해서 술이나 한잔 때리고. 이렇게 사는게 맞는 거겠지? 돈을 주니까 일은 하겠는데, 언제 짤릴지 모르니 짤릴 때까지는 죽은 듯 붙어 있는게 맞는 거겠지? 괜히 이 나이에 뛰쳐나갔는데 다른 데서 안써주면 허무하니 일이 많은걸 다행이라 생각하고 열심히 일하는게 맞는 거겠지? 이제 놀러다녀보고 싶은데도 딱히 없고, 이래저래 돌아다녀봤자 기름값만 나오니 그냥 들어와 있는 물에서 열심히 노 젓는게 맞는 거겠지? 집에 있으면 몸뚱이만 굳으니까 휴일에도 알바나 하면서 한 푼이라도 더 버는게 맞는 거겠지? 요즘은 그저 집이나 하나 장만하겠다는 마음에 술값 빼고 다 아끼고 살고 있는데, 집값이 월급보다 더 빨리 올라서 이대로는 영원히 올라탈 수 없을 것 같은데, 대출도 다 줄었지만 운 좋게 영끌해서 집 한채 장만한다고 한들, 이자만 갚다가 죽게 되겠지. 그래도 열심히 일하고 벌어서 집을 장만 하는게 맞는 거겠지? 그렇겠지? 확실하냐??

가끔은 전 직원 퇴근하고 홀로 사무실에 앉아 있으면 이런 생각이 든다. 내가 일을 못하는 건지. 나만 열심히 일을 하는 건지. 내가 제일 늙어서 안 짤릴라고 열심히 하는 건지. 어렸을 때부터 아이큐가 좋다고 생각해 본 적 없고, 난 단지 '노력파' 란 생각으로 나름 성실히 살아 왔고, 그러다 보니 뭔가를 효율적으로 하는 방법은 모르는 거 같고, 융통성도 별로 없는 거 같고, 쓸데없이 완벽을 추구하려고 하고, 그러면서 완벽하게는 못하고. 그렇다고 아이큐가 낮은 사람이 무언가를 연구해서 아이큐를 높여 보겠다는 것은 아니고, 그냥 나를 파악했으니 그냥 그런 줄 알고 그냥 이렇게 살겠다는 얘기이다. 바뀔 수 있는 문제도 아니고, 아무리 그래도 중간은 하겠지... 라는 영혼없는 마인드로...

이제 뭔가를 한다는게, 딱히 하고 싶지도 않고, 흥미로운 것도 없고, 술과 안주에 대한 마음도 예전 같지 않지만 그래도 그나마 아드레날린 뿜을 수 있는건 술 뿐이지! 짠하다고 생각할 테지만 그래도 지금은 그냥 사무실에 앉아서 컴퓨터나 두드리는게 제일 편안하다. 더울 때 시원하고, 추울 때 따듯하고, 밥주고, 재워주는 사람은 없어도 맘만 먹으면 잘 수도 있고. 왜 따로 월세를 내고 살고 있는거지... 그래도 흥미(?)로운 무언가가 언젠간 생길지 모르니, 몸이나 녹슬지 않게 기름칠 잘 해놔야지. 언젠가 다시 아드레날린이 솟구칠 날을 기다리며...

간만에 ingress 하나 생성하려는데 태클이...

$ kubectl describe ingress my_ingress -n my_namespace

  Type     Reason             Age    From     Message
  ----     ------             ----   ----     -------
  Warning  FailedDeployModel  3m41s  ingress  Failed deploy model due to AccessDenied: User: arn:aws:sts::110111011101:assumed-role/myEKSLoadBalancerControllerRole/1234561234561234561 is not authorized to perform: elasticloadbalancing:AddTags on ause no identity-based policy allows the elasticloadbalancing:AddTags action

구글에서는 위 에러 메시지와 관련된 내용은 찾기 어려웠다. AWS 문서 뒤적이며 loadBalancerController 생성하는 부분을 찾아보니, iam_policy.json 파일이 v2.3.0 에서 v.2.5.4 로 업데이트 되어 있었고, 아래 정책이 추가된 것을 확인했다.

        ...
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:AddTags"
            ],
            "Resource": [
                "arn:aws:elasticloadbalancing:*:*:targetgroup/*/*",
                "arn:aws:elasticloadbalancing:*:*:loadbalancer/net/*/*",
                "arn:aws:elasticloadbalancing:*:*:loadbalancer/app/*/*"
            ],
            "Condition": {
                "StringEquals": {
                    "elasticloadbalancing:CreateAction": [
                        "CreateTargetGroup",
                        "CreateLoadBalancer"
                    ]
                },
                "Null": {
                    "aws:RequestTag/elbv2.k8s.aws/cluster": "false"
                }
            }
        },
        ...

AWS 콘솔에서 myEKSLoadBalancerControllerRole 을 찾아 연결된 정책 AWSLoadBalancerControllerIAMPolicy 에 위 스니펫을 삽입하여 해결...

내용은 대충 TargetGroup / LoadBalancer 생성할 때 리소스에 태그지정하는 권한 같은데... 참 쓰잘데기 없다. 아니 매년 이렇게 미친듯이 강제로 업데이트 하는게 맞는거야? 

(참고) https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/aws-load-balancer-controller.html

<좌: 2022년 9월 / 우: 2024년 1월>

한번도 아프지 않고 잘 자라고 있는 드라세나 콤팩타.

완벽한 음지에서 1년 반을 있었고, 방문 사이로 들어오는 오전 햇빛 때문에 살짝 문쪽으로 아주 살짝 휘고 있다 ㅋ 크기와 음지를 감안하고, 젓가락 꼽아서 거의 말랐다 싶으면 물을 듬뿍 줬다. 대충 30일~40일 정도. 화분 길이가 길쭉해서 젓가락이 얼마 안들어가니 얼추 맞는 것 같다. 지금껏 잎 3장 정도가 끝부분이 새까맣게 탄 것들을 발견했는데, 아마도 과습일 때 그런 현상이 나타나지 않나 싶다. (사실 잘 모름.) 1년 반 동안 1도 안 큰줄 알았는데, 사진으로 이렇게 비교해보니 키가 좀 크긴 했네. 잎이 시작되는 부분을 보면 목대가 얇아진게 보이는데, 유튜브에서 보니 저 부분을 야곰야곰 뜯어주면 키가 잘 자란다고... 예전 사진이 훨씬 풍성해 보이긴 하네ㅎㅎ; 이론상으로 보면 그럴 듯 하다. 잎을 잘라내면 그만큼 영양분은 확보될 것이고, 그 영양분이 키와 잎으로 갈 수 있다는 생각이 든다. 하지만 1년 반을 키워보니, 키는 그냥 햇빛과 물이 충분하면 잘 자랄 것 같다. 잎을 잘라내는 것은 그저 디자인의 목적이 더 크지 않을까... 연꽃같은 분위기를 내느냐, 먼지털이(?) 같은 기다란 분위기를 내느냐. 나는 이제는 잎을 잘라내지 않을 예정이다. 공기정화 목적으로 들인 식물들이니 잎이 많은 것이 더 합리적. 유튜브 영상에서는 너무너무 잘 자라서 천장에 닿을 듯 하던데, 그 정도면 너무 피곤할 것 같음. 목대도 이리저리 휘어있어서 보기에도 그닥. 4계절을 잘 지냈으니 앞으로도 별 일 없을 것 같고... 넌 그저 음지에서 조금씩만 건강히 자라거라~~

1년 만에 유일하게 실패한 스투키. 8줄기 정도 있엇는데, 6개월만에 무름병 때문에 하나 보내고, 1년 정도 될 무렵 스피드하게 하나씩 맛이 갔다. 그래도 1년 동안 키워본 초식남으로 스투키만 살리지 못한 이유를 꼽아보았다.

확실히 과습에 취약하다

집에 18종류의 다양한 식물들이 있고, 1년 동안 물 주는 스타일은 모두가 같았다. 젓가락 꼽고 거의 말랐다 싶을 때 흠뻑줬고, 6개월 이상 스투키도 별 일이 없었던 것을 보면 그 방법이 틀리지 않았다고 생각했다. 하지만 겨울을 지내면서 무름병이 처음으로 생겼을 때, 그 때부터라도 흙 마름 체크를 더 꼼꼼히 했어야 했는데, 화분에 너무 빼곡 했던 줄기들을 때문에 대충 확인하고 물을 줬던 것 같다. 무름병이 신호를 줬을 때, 오히려 굶기듯이 키웠다면 아직 죽지는 않았을 듯. 더욱 과습이라고 느끼기 어려웠던 것은 바로 옆에 금전수도 똑같은 화분에 똑같이 빼곡하게 꼽혀 있는데, 그 아인 겁나 잘자랐음. 같은 다육이더라도 잎이 있고 없는 차이가 있긴 하지만 그 때는 '금전수도 잘 자라니, 너도 문제 없어야지.' 라는 생각이었다.

지금도 물 주는 스타일은 변함이 없다. 언제나 흠뻑~ 단지 식물마다 또는 계절마다 흙이 완전 말랐을 때 흠뻑 주느냐, 10% 정도 아직 젖어 있을 때 흠뻑 주느냐, 30% 정도 젖어 있을  때 흠뻑 주느냐, 그 차이.

그리고 예전에 스투키에서 첫 새싹을 마주했을 때 반가움 마음에 검색해보니, 본체 줄기의 영양분을 나누게 되니 뽑는 게 좋다는 글들을 보았는데 내가 볼 땐 전~혀 상관없음. 외관상 보기 싫으면 뜯으면 되고, 아니면 놔두면 됨. 만약 다음번에 스투키를 사게 된다면 저런 잎꽃이 한거 말고, 본체 튼튼한 스투키를 사보는 걸로...

... 스킨답서스에 꽃이 피었을 때, 배경으로 나왔던 가장 최근 사진.

Apache POI 는 MS office 문서포맷을 Java 로 사용할 수 있는 API 를 제공한다.

보통 WorkBook 으로 문서를 만드는 예제나, 암호화된 문서의 암호를 삭제시킬 수 있는 예제들이 떠돌고 있다.

MultipartFile 로 엑셀파일 전달 받고, 해당 파일에 암호 설정해서 돌려주는 API 를 만들어 봤다.

 Gradle 

dependencies {
    implementation 'org.apache.poi:poi:5.2.2'
    implementation 'org.apache.poi:poi-ooxml:5.2.2'
}

 Java 

@PostMapping("/excel/encrypt")
public ResponseEntity<ByteArrayResource> excelEncrypt(@RequestParam MultipartFile file) {

    String[] extensionArr = {"xls", "xlsx"};  // 97~, 2007~
    String[] mimeTypeArr = {"application/vnd.ms-excel", "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"};
    // 파일검증 생략

    // apache poi 엑셀 암호화
    ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
    try (POIFSFileSystem fs = new POIFSFileSystem()) {
        EncryptionInfo encryptionInfo = new EncryptionInfo(EncryptionMode.agile);

        Encryptor encryptor = encryptionInfo.getEncryptor();
        encryptor.confirmPassword("password!@#$");

        try (OPCPackage opc = OPCPackage.open(file.getInputStream());
             OutputStream outputStream = encryptor.getDataStream(fs)) {
            opc.save(outputStream);
        }
        fs.writeFilesystem(byteArrayOutputStream);
        byteArrayOutputStream.close();
    } catch (Exception e) {
        logger.info(e.getMessage());
    }

    HttpHeaders header = new HttpHeaders();
    String encFileName = URLEncoder.encode(file.getOriginalFilename(), StandardCharsets.UTF_8).replace("+", "%20");
    header.setContentType(MediaType.parseMediaType(file.getContentType())); // <- 지정하지 않아도 무관
    header.set(HttpHeaders.CONTENT_DISPOSITION, "attachment; filename*=utf-8''enc_" + encFileName);

    return new ResponseEntity<>(new ByteArrayResource(byteArrayOutputStream.toByteArray()),
                    header, HttpStatus.OK);
}

음~ 잘된당~

용량을 10M 정도 넘겨봤더니, 에러 발생. 늘려보려 했는데... 실패!

Tried to allocate an array of length 132,636,469, but the maximum length for this record type is 100,000,000.
If the file is not corrupt or large, please open an issue on bugzilla to request 
increasing the maximum allowable size for this record type.
As a temporary workaround, consider setting a higher override value with IOUtils.setByteArrayMaxOverride()