FIFA Manager 12 치트 (돈 늘리기)

FIFA MANAGER 12 에서 메모리 에딧으로 감독의 게임 머니를 증가시키는 방법입니다.

1. TSearch 를 다운 받아 실행할 준비 해둡니다.
2. 감독 개인 생활 메뉴로 가서, Stock Market 으로 갑니다.
3. 주당 가격이 가장 비싼 구단의 주식을 삽니다.
4. TSearch 에서 구매한 주식의 값을 Search 합니다.
5. 게임에서 주식을 더 구매합니다.
6. 4의 결과에서 증가한 주식의 수치만큼을 다시 검색합니다.
7. 결과가 3개가 될 때까지 5~6을 반복합니다.
8. 결과가 3개가 되면, 가장 밑에 있는 (메모리 주소값이 가장 큰) 것을 더블 클릭하여 999999999 로 고칩니다.
9. 게임으로 가서 주식을 9주만 남기고 모두 팝니다. 만약 모두 다 팔면 검색 과정을 다시 되풀이 해야 되므로 9주를 남깁니다.
10. TSearch 로 가면 99..99 인 값이 9로 되어 있을 겁니다. 이것을 다시 999999999 로 늘립니다.
11. 원하는 액수가 될 때까지 9~10 반복합니다.
12. 개인 자산이 늘어나면, 클럽에 기부 등을 하여 원하는 일을 할 수 있게 됩니다.

Shell Prompt 모양 바꾸기

프롬프트의 모양을 변경할 host 의 사용하는 계정의 shell profile 에 아래 내용을 추가한다.

PS1="`hostname`@$LOGNAME:\$PWD  #  "

export PS1

shell profile 은 대게 로그인 한 계정의 홈 디렉토리에 profile 이란 이름으로 존재한다. 파일의 위치와 모양은 시스템의 설정에 따라 다를 수 있으므로 주의.

이렇게 설정하면,

(호스트 이름)@(로그인계정):\(현재디렉토리)  #

와 같은 형태로 프롬프트가 변경된다.

한글/중문/영문 직급 이름

회장 : Chairman of the Board(of Directors) 명예회장 : Honorary Chairman
부회장 : Vice Chairman & CEO 대표(사장) : President 또는 Representative
부사장 : Senior Executive Vice President 전무이사/전무 : Senior Managing Director
상무이사/상무 : Managing Director 이사/이사대우 : Director
상임고문 : Executive Advisor 감사 : Auditing Director 또는 Auditor
고문/자문 : Advisor 소장 : Director 지점장 : Branch Manager
공장장 : Plant Manager 또는 Factory Manager
부장 : General Manager 또는 Department Manager 본부장 : Devision Director
부장대리 : Deputy General Manager(또는 Acting General Manager)
차장 : Deputy General Manager 원장(의료기관) : Chief of Medical Clinic
관장(미술관등) : Director 비서실 : Office of the Secretary
본사 : Head office 실장,주사 : Manager 과장 : Manager 또는 Section Chief
과장대리 : Acting Manager 대리 : Assistant Manager
계장 : Subsection Chief 또는 Senior Staff 주임 : Assistant Manager , Supervisor
주임기사 : Staff Enginner 기사 : Enginner 수석연구원 : Principal Research Engineer 책임연구원 : Senior Research Engineer
선임연구원 : Research Engineer 전임연구원 : Associate Research Engineer
고문변호사 : Legal Adviser 또는 Corporate Lawyer
촉탁사원 : Non-Regular Staff 주임연구원 : Assistant Research Engineer
상임고문 : Excutive Advisor 전문위원 : Research Fellow
기획실 : Planning Team 법무팀 : Law Dept. 총무부 : General Affairs Dept.
인사과 : Personnel Section 홍보실 : Public Relations Section
시설관리부 : Facilities Management Dept. 전략기획팀 : Plan Dept.
해외사업팀 : International Development Dept.
영업기획팀 : Sales Planning Team 영업1팀 : Sales Team 1
부산지사(지점) : Busan Branch 구매부 : Purchasing Dept.
재경부 : Finance & Accounting Dept. 경영개선팀 : Management Improving Team
고객만족실 : General Affairs Dept. 기술지원팀 : Technical Support Team
해외사업부 : Overseas Business Division 국내물류부 : Logistics Managemet Dept.
연구기획팀 : R&D Planning Team 통신연구소 : Communication Research Center
연구실 : R&D Lab. 생산관리팀 : Manufacturing Control Team
공장관리팀 : Factory Planning Team 품질관리팀 : Quality Contorl Team
●「～部」는 ～Department、「～課」는～Section、「～室」은～Office 라고 표기함

회 장 會長 Chairman 부회장 副會長 Vice Chairman 사 장 社長 President
부사장 副社長 Senior Executive Vice Presiden 전무이사.전무 專務理事 Senior Managing
Director 상무이사.상무 常務理事 Managing Director
이사.이사대무 理事 Director 감 사 監事 Auditor General 고문.자문 顧問
Advisor 부 장 部長 General Manager 본부장 本部長 Director
부장대리 部長代理 Deputy General Manager 차 장 次長 Deputy General Manager
실 장 室長 General manage 과 장 課長 Manager 대 리 代理 Assistant manager
계 장 係長 Chief 주 임 主任 Assistant manager, Supervisor
주임기사 主任技士 Staff engineer 기 사 技士 Engineer
수석연구원 首席硏究員 Principal Research Engineer
책임연구원 責任硏究員 Senior Research Engineer
선임연구원 先任硏究員 Research Engineer
전임연구원 傳任硏究員 Ssociate Research Engineer
주임연구원 主任 Assistant Research Engineer
상임고문 常任顧問 Executive Advisor 전문위원 專門委員 Research Fellow
법무팀 法務硏究員 Law Dept. 전략기획팀 戰略企劃 lan Dept.
해외사업팀 海外事業 International Development Dept.

기 획 실 企 劃 室 Planning Dept 고객만족실 顧客滿足室 General Affairs Dept
총 무 부 總 務 部 General Affairs Dept 경 리 부 經 理 部 Accounting Dept
택배업무부 宅配業務部 Parcel Service Support Dept
택배영업부 宅配營業部 Parcel Service Sales Dept
택배마케팅부 宅配마케팅部 Marketing & Pricing Dept
시설관리부 施設管理部 Facilities Management Dept
국내물류부 國內物流部 Logistics Management Dept
물류개발부 物流開發部 Third Party Logistics Dept
항공업무부 航空業務部 Air Operation Dept
해운업무부 海運營業部 Ocean Operation Dept
해운영업부 海運營業部 Ocean Sales Dept
경영개선팀 經營改善 Management Improving Team e- BIZ부
e-BIZ部 e-Business Dept
[출처] 영어 직급작성자 다크

클라우드 컴퓨팅 설명/전망

• 클라우드 컴퓨팅의 정의

컴퓨팅이 전기와 수도 같은 유틸리티가 되는 것으로 온디멘드 아웃소싱 서비스로 분리할 수 있다.

• 가상화가 클라우드 컴퓨팅에 기여한 점

물리적으로 분산된 자원을 가상화 기술로 하나의 리소스 풀(Resource pool)로 묶고 작업요구수준(Workload)에 따라 자원을 배분하여 사용할 수 있게 함. 인프라 중 어떤 리소스는 항상 활발하게 이용되고 어떤 리소스는 일부분 밖에 사용되지 않는다면 전체적인 활용도 및 효율이 낮다고 할 수 있다.
때문에 일부분 밖에 사용되지 않는 리소스들의 여력을 가상화로 묶어서 하나의 자원으로 활용할 수 있게 한다.
그리드 컴퓨팅과 다른 점은 유휴의 자원을 묶되 네트워크 상의 모든 컴퓨팅 자원을 활용하는 것이 아니라, 개별 사업자가 소유하고 있는 자원을 가상화를 통해 리소스 풀을 구성하는 것이 다르다. 그리드 컴퓨팅은 네트워크 상의 활용 가능한 모든 컴퓨팅 자원을 묶는다.

• 구글의 클라우드 컴퓨팅

구글의 경우 자사의 네트워크 자원을 활용하여 Open API 를 개인 사용자에게 제공하기 시작했다. 구글은 App Engine 이라는 이름으로 PaaS(개인 사용자 제공)를 시작했으며 곧 SaaS(기업 사용자)로 서비스가 확대 될 것으로 기대된다.

• 클라우드 컴퓨팅이 가진 한계와 단점

1. 서비스 안정성에 대한 불안

서비스 제공 측의 문제로 서비스가 중단 될 경우 미션 크리티컬 한 금융 서비스와 같은 경우는 매우 큰 대란이 야기될 수 있다.

1. 자료에 대한 불안감

개인의 자료가 물리적으로 분산된 장치에 저장되어서 관리와 저장소를 알 수 없음

1. 낮은 표준화 수준으로 서비스 제공자 간의 자료 이동이 어려움

각자 서비스 제공자들이 고안한 플랫폼에서 클라우드 컴퓨팅 서비스가 제공되므로 한 클라우드에 속한 사용자가 다른 클라우드의 서비스를 이용하는데 제약을 받으며 자료의 이동이나 서비스 이용이 불가능하다.

1. 아직 성숙하지 않은 시장

기업에 서비스를 제공하는 빈도가 늘어나야 전체 시장이 성장하게 된다. 특히 국내 인터넷 이용 환경은 오픈 플랫폼 보다 폐쇄적인 맞춤형 웹 서비스을 네티즌이 더 선호하므로 PaaS -> SaaS로 자연스러운 시장확대가 이루어 지기 어려운 점이 있음

Welogic 어드민 암호 재설정 (Weblogic 9 이상)

1. 암호를 변경할 Weblogic domain 의 전체 server 를 shutdown
2. ${DOMAIN_HOME}/security/DefaultAuthenticatorInit.ldift 파일을 Backup
3. ${DOMAIN_HOME}/boot.properties 파일을 열어서 수정하고 없으면 새로 생성
   [파일내용]
   username=weblogic
   password=[변경 password]
4. ${DOMAIN_HOME}/servers 디렉토리를 servers.org 로 이름을 변경
5. ${DOMAIN_HOME}/bin/setDomainEnv.sh 를 실행
6. 쉘에서,
   $$> java weblogic.security.utils.AdminAccount weblogic [변경 password] .
   를 실행
7. 5에서 생성된 DefaultAuthenticatorInit.ldift 파일을 ${DOMAIN_HOME}/security/ 로 copy
8. Admin server 를 기동하여 결과 확인

ssh 로그인 없이 자동 접속

A 라는 서버에서 B 라는 서버로 SSH 접속을 시도할 때 암호 입력 없이 바로 접속되는 방법

1. A 서버에 ssh 접속
2. $$> ssh-keygen -t rsa
   passphrase 를 입력하라는 메시지가 나오면, 그냥 엔터(=null) 입력한다.
3. $$> ssh-copy-id -i ~/.ssh/id_rsa.pub {자동 접속할 B서버 계정}@{B서버IP 또는 도메인} 실행
4. Password: 메시지가 나타나면 자동 접속할 계정의 암호를 평상시처럼 입력한다.
5. 이후부터 ssh 접속 시 암호를 물어보지 않는다.

만약 이렇게 하였는데도 암호를 계속 물어본다면 B 서버의 sshd 의 설정 파일을 열어서 strict 라는 부분을 찾아서 false 로 고치도록 한다.

sshd 의 설정 파일은 OS 마다 다르지만 대게 /etc/sshd/sshd_config 파일이므로 vi 로 열어서 수정하면 된다.

이 방법은 보안상 매우 위험한 방법이므로, 외부와 확실히 단절된 LAN 내부 연결 호스트끼리만 사용하도록 한다.

MySQL com.mysql.jdbc.PacketTooBigException

• MySQL 을 사용하는 게시판에 첨부물 등을 upload 할 때, 첨부물 파일을 MySQL 내부에 저장하도록 설정이 되어 있으면 특정한 크기 이상의 첨부물을 등록할 때 Exception 이 발생한다.

Caused by: com.mysql.jdbc.PacketTooBigException: Packet for query is too large (11021370 > 1048576). You can change this value on the server by setting the max_allowed_packet' variable.

• 그 원인은 MySQL 환경설정 중에 packet 최대치를 제한하는 옵션이 있기 때문인데 시동 옵션에 이를 명기하지 않으면 default=1MB 로 MySQL이 시동되기 때문에 이보다 더 큰 첨부파일은 MySQL 에 등록되지 않는다.

• MySQL 시동 옵션 중에 아래를 추가하도록 한다.
  ./mysqld_safe --user=mysql --max_allowed_packet=32M &

자바 Could not open jvm.cfg 에러 해결방법

Java 프로그램을 실행할 때 이런 에러를 만나게 되면 아래 순서대로 레지스트리를 편집하여 문제를 고칠 수 있게 된다.

1. regedit 레지스트리 편집 프로그램을 연다.
2. HKLM/SOFTWARE/Javasoft/JavaRuntimeEnvironment 이란 key 를 찾아간다.
3. Key 의 내용 중 CurrentVersion 을 찾아 더블클릭한다.
4. CurrentVersion 의 내용에 있는 디렉토리가 실제로 내가 원하는 Java 가 설치된 디렉토리인지 확인하여 수정한다.

이 에러메시지가 발생하는 원인은, 이전에 설치된 JVM 의 레지스트리 내용이 프로그램 삭제 때 그대로 남아 있어서 그렇다.

Amazon EC2 환경의 디플로이 자동화 아이디어

• 전제

모든 EC2 인스턴스는 각기 서비스할 모듈(컴포넌트) 단위로 secutiry 그룹을 갖는다. 예를 들어 하나의 인스턴스에서 2개의 컴포넌트가 서비스되면 각각 컴포넌트마다 별도의 security 그룹을 갖는다.

• 동작

배포 서버는 아마존 EC2 admin API 에 접근하여 특정 security group 에 대한 member list 를 제공 받는다. 배포 명령이 내려지면 제공 받은 member list 에 대하여 배포 동작을 수행한다.

• 장점

배포를 위하여 별도의 xml 이나 설정, history 들을 보관할 필요가 없음

• 생각

ANT script 에 배포에 관련된 IP 어드레스나 계정 정보가 나열되어 있는 것은 최소한의 정도만 있는 것이 좋을 것으로 생각한다.

tail 명령의 위험성

Web Application Server 를 구동할 때 에러가 발생하는 것을 사전에 탐지하기 위하여, WAS 구동 script 에 log 를 확인하기 위한 UNIX shell tail 명령어를 걸어두는 경우가 많다. 아래가 tail 명령을 사용한 WAS startup script 이다.

#!/bin/sh

JAVA_OPTIONS=......
CLASS_PATH=......

nohup java -cp $CLASSPATH $JAVA_OPTIONS > waslog.out &

tail -f waslog.out

이렇게 작성하면 Java 로 구동된 WAS 가 발생하는 모든 표준 출력이 화면으로 redirect 된다.

그런데, 이것은 대단히 위험한 script 작성 방법 일 수 있다. 큰 시스템 장애를 만들 수도 있다. 만약 개발자 또는 시스템 관리자가 WAS 구동 이후 log 를 tail 하고 있는 상태에서정상적인 UNIX 시스템 Logout 없이 Shell program 이 종료 되면 WAS 가 kill 될 수 있고, 운영 중인 시스템에 큰 데미지를 입힐 수 있다.

그 이유를 알기 위해서는 nohup 으로 WAS 를 구동할 때 일어나는 Process grouping 과 Shell process 의 child invoke 매커니즘을 이해해야 한다.

첫번째, nohup 명령의 동작 특성 대하여 알아보자.

nohup POSIX 명령어는 Process 가 HUP(=Hang up) Signal 을 무시하도록 만든다. 이 HUP Signal 은 사용자가 접속한 Session 의 Shell Process 가 통신을 종료할 때 자식 Process 들에게 전파된다. 그래서 UNIX Shell 에 접속한 상태에서 logout 하는 경우 그 Shell 이 실행했던 모든 Program 이 종료된다. nohup 으로 Process 를 실행하면 HUP Siganl 을 무시하기 때문에 사용자의 login 여부와 상관없이 시스템에서 계속 실행이 되는 것이다.

OS 마다 다르긴 한데 nohup 으로 띄운 Process 는 자신을 실행한 Parent process 가 종료되면 사용자 Session 의 Shell process 의 자식으로 입양되었다가, Shell 이 종료되면 HUP Signal 을 받으면 일시적으로 Orphan process 가 되었다가 System Mothe shell process(=PID 1) 로 입양된다.

두번째, UNIX System 의 Process invocation 에 대하여 알아보자.

아래 그림은 UNIX System 에 접속한 상태에서 WAS 가 구동될 때 Process 의 가계도이다.

nohup Process 가 WAS 프로그램이다. 앞에서 보았듯이 Startup shell script process 가 종료되면 User shell process 로 WAS process 가 입양된다. 그러나 parent 가 종료되지 않으면 계속해서 Shell script process 의 자식으로 남아있게 된다.

tail 명령은 Shell script process 의 Child process 로 구동되는데, 이 녀석은 무한루프를 돌면서 stdout 을 가로챌 준비를 한다. 그러므로 Shell script process 는 자식이 작업을 마치길 기다리느라 종료되지 않는다.

이 상황에서 HUP Signal 이 발생하면 User shell 이 HUP Signal 을 접수하여 자식들에게 HUP 을 전파한다. 그런데 Shell script process 는 HUP 을 전파하지 않고 자신이 종료되어야 하기 때문에 아직 살아있는 Child process 에게 Kill Signal 을 전파하게 된다.

그 결과로 tail 뿐만 아니라 WAS Process 도 HUP 이 아니라 Kill signal 을 받아 죽게 된다.

truss -t\!all -sall -Sall -f ./startWAS.sh >& trusslog.log &

위 명령어는 startWAS.sh 를 실행하였을 때 받게되는 모든 OS Signal 을 trusslog.log 에 저장하는 명령인데 실제로 tail 이 포함된 shell process 가 어떤 OS Signal 을 받는지 기록해보면 tail 명령의 위험성을 더 잘 알 수 있을 것이다. 그리고 HUP Signal 을 고의로 발생시키려면 tail 이 되고 있을 때, Shell program 을 강제종료 시키면 된다.

tail 명령은 WAS 구동 관련 script 에 절대로 있어서는 안 된다. 따로 로그 확인을 위한 script 를 작성하는 것이 좋다.