윈도우 xp 원본 파일 복구하기

윈도우 xp 사용 중 원본 파일이 변경되었을 경우, 원본 파일로 복구하는 방법입니다. 

1. 윈도우 설치시 사용한 CD/DVD 를 CD/DVD 롬에 삽입니다. 
2. [시작] 버튼을 누릅니다. 
3. [실행(R)] 을 클릭합니다. 
4. sfc /scannow 라고 적은 후 엔터키를 누릅니다. 

windows XP 복구방법

부팅이 불가능 할 경우 xp 의 복구콘솔을 이용해 부팅 파일을 복구 시킬수 있습니다. 

순서는 다음과 같습니다. 

우선 Windows XP Pro 설치시디를 시디롬에 넣고 재부팅 합니다. 

재부팅시 del 또는 F2 키를 이용해 cmos 로 들어가서 첫번째 부팅순서를 CD-Rom 으로 설정한뒤 저장하고 나옵니다. 

CD-Rom 에서 xp 설치 시디를 읽으면서 Press Key... 가 나오면 아무키나 눌러줍니다. 

XP 설치 화면으로 바뀌고 계속설치(ENTER) , 복구콘솔(R) 화면이 나올때 R 키를 누릅니다. 

키보드 및 운영체제 위치를 선택해 줍니다. 

XP 설치시 입력했던 administrator 비밀번호를 입력합니다. 

복구콘솔이 나오면 C:\Windows> 이 화면에서 CD 를 입력해 C:\> 으로 이동합니다. 

C:\>Fixmbr \device=harddisk0 입력 합니다. 만약 물리적인 하드가 두개고 두번째 하드에 XP 가 설치되어 있다면 harddisk1 로 입력해 주십시오. Y/N 이 나오면 Y 를 선택합니다. 

C:\>Fixboot c: 입력 후 엔터 

C:\>Chkdsk c: 입력 후 엔터 

다 끝나면 C:\>Exit 입력 후 시디롬에서 XP 시디를 빼고 정상부팅이 되는지 확인합니다.

열린포트 확인하는 방법

시스템 명령어인 netstat 를 사용하는 방법

#netstat -nap (열려 있는 모든 포트)
#netstat -l 또는 netstat -nap | grep LISTEN (LISTEN 되는 모든 포트)
#netstat -nap | grep ESTABLISHED | wc -l ( 모든 서비스 동시 접속자 수)
#netstat -nap | grep :80 | grep ESTABLISHED | wc -l ( 웹 동시 접속자 수)


포트스캔 명령어로 확인 하는 방법

# TCP 포트 확인 방법
nmap -sT -p 1-65535 localhost
# UDP 포트 확인 방법
nmap -sU -p 1-65535 localhost
# 네트워크에 열린 포트 확인
nmap -sX -p 22,53,110 211.239.111.*


lsof 명령어로 확인 방법

# 모든 네트워크 소켓 확인
lsof -I

tomcat 여러개의 포트 사용하기

톰캣에서도 MS의 IIS와 같이 포트 번호에 따라 호스팅하는 것이 가능하다.(근데 웨케힘드노)

TOMCAT_HOME\conf\server.xml 을 열고 아래와 같이 Service 엘리먼트를 추가한다.

아래 좋은 블로그가 있어서 펌해왔다. ^__^) b

 아파치와 연동없이 톰캣만으로도 하나의 IP로 다수의 웹사이트를 운영하는 것이 가능하다.
(아파치와 톰캣을 연동하는 방법에 대해서는 차후에 자세히 올리도록 하겠다)

특히 개발자의 경우 여러개의 프로젝트를 개발하거나 테스트하고자 할 때 웹사이트를 여러개 운영해야한다. 다수의 웹 사이트를 세팅하는 방법은 크게 2가지가 있다.

• 가상호스트를 이용하는 방법
• IP Address의 port를 여러개 사용하는 방법

가상호스트를 이용하는 방법은 도메인을 이용하여 실제로 서비스를 운영하는 경우가 아니면 개발자에겐 별 의미가 없다. 여기서는 두번째 방법인 IP 어드레스의 포트를 이용하는 방법에 대해서 설명하겠다. (바로가기 : 톰캣에서 가상 호스트를 이용하는 방법)

우선 설치 환경은 다음과 같다.

• O/S : Windows XP (난 아직 리눅스를 잘 모른다. 비슷하겠지만 테스트해보지 않았다)
• Tomcat 6.0 (정확히는 6.0.10) : 다운로드

설명의 편의를 위해 톰캣의 설치 디렉토리는 'TOMCAT_HOME' 으로 표기할 것이다. 참고로 내 경우는 C:\Server\Tomcat6.0 이다.

설정하는 방법은 간단하다. /TOMCAT_HOME/conf/에 있는 server.xml 파일만 수정하면 끝이다. server.xml의 쓸데없는 주석부분을 다 없애고 핵심부분만 남겨놓으면 아래와 같다.

<Service name="Catalina">
  <Connector port="8080" protocol="HTTP/1.1"
   maxThreads="150" connectionTimeout="20000"
   redirectPort="8443" />
  <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />  <Engine name="Catalina" defaultHost="localhost">
   <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
    resourceName="UserDatabase"/>
   <Host name="localhost"  appBase="webapps"    unpackWARs="true" autoDeploy="true"
    xmlValidation="false" xmlNamespaceAware="false">
   </Host>
  </Engine>
 </Service>

우선 빨간색으로 표시한 부분만 이해하고 넘어가도 상관없다.
Connector port="8080"은 HTTP로 넘어오는 포트를 지정하는 것이다. 톰캣의 기본 포트가 8080인 이유가 여기에 있다. 따라서 8080 대신 기본 80포트를 사용하고 싶다면? 바로 이 부분을 port="80"으로 바꾸어주면 된다.

다 음, Host 지시어의 appBase="webapps" 는 웹어플리케이션(웹사이트)의 위치를 나타낸다. appBase="./webapps"와 같은 의미다. 실제 위치는 TOMCAT_HOME/webapps이다. 물론 "d:/weapps/myweb1" 과 같이 절대경로로 지정하는 것도 가능하다.

그럼 웹사이트를 하다 더 추가하고 싶다면? 위의 <Service>...</Service>를 하나 더 만들어 버리면 된다. 위의 코드를 복사한 다음 server.xml 에 추가한다. 그리고 빨간색으로 표시한 부분만 수정하자.

<Service name="Catalina2">
  <Connector port="9090" protocol="HTTP/1.1"
     maxThreads="150" connectionTimeout="20000"
     redirectPort="8443" />
  <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
 
  <Engine name="Catalina" defaultHost="localhost">
   <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
     resourceName="UserDatabase"/>

   <Host name="localhost"  appBase="d:/webapps/myweb2"
    unpackWARs="true" autoDeploy="true"
    xmlValidation="false" xmlNamespaceAware="false">
   </Host>
  </Engine>
 </Service>

다른 웹어플리케이션을 돌리기 위해 서비스를 하나 더 추가한 것이다.
port="9090" 은 새로 추가하고 싶은 포트이다.
appBase="d:/webapps/myweb2"는 9090 포트에서 돌아갈 웹사이트 위치이다.

이제 server.xml 설정은 끝난 것이다.
마지막으로 웹사이트의 ROOT 디렉토리를 지정해주자. 아래의 폴더를 생성한다.

d:/webapps/myweb2/ROOT/   (
d:/webapps/myweb2/ROOT/WEB-INF/
(WEB-INF 폴더를 만들고 web.xml 파일을 추가한다. 그냥 /TOMCAT_HOME/webapps/ROOT/WEB-INF/에 있는 web.xml 을 복사하면 된다.

무지 간단하다. 하지만 난 이 간단한 것을 위해서 하루종일 삽질해야만 했다. 검색해 보아도 문서는 많은데 실제 도움이 될만한 것이 별로 없었다.

테스트하기 위해 ROOT/index.html 또는 index.jsp를 만든다.
이제 톰캣을 재시작하고 웹브라우저로 접속해 보자.http://localhost:8080
http://localhost:9090

출처:톰캣 포트번호 여러개 사용하기

Unix 명령어

파일의 겟수를 체크할 경우
ls -l |wc -l
(예시)
nsdiap2:tmax [/app/tcpor/webapps.bak/WEB-INF/lib]# ls -l /app/tcpor/webapps/WEB*/lib |wc -l

크롬 에러시 조치 방법

\Local Settings\Application Data\Google\Chrome\Application\chrome.exe" --no-sandbox --new-http

no-sandbox --new-http

을 단축키에 추가해준다

FireBug Tips and Tricks

There is so much power packed into this little FireFox plug-in. It is truly a revolutionary tool for web developers. Here is a quick and dirty set of its most powerful features.
To get started, open up firebug using F12 or by clicking its icon in the lower right corner of FireFox. To jump straight to the console and start typing commands you can use the Ctrl+Shift+L keyboard shortcut.

From here you can type commands. Try entering document. This will bring up the document DOM object and you can click on that link to get to the DOM and inspect all of the properties of the document object. A shortcut is also available by typing inspect(document) etc. You can use $ and $$ as in Prototype, such as $(‘firebug’) and inspect($$(‘.firebug’)). Use the up and down arrows to cycle through command history.

• Use console.log and sprintf formatting commands for debugging.
• Use console.info, console.warn and console.error to set your debugging levels.
• Use console.time to log the time your functions take to run.
• Use the error console to view the stack trace of the errors.

You can download Firebug Lite to make these methods work in Internet Explorer. I recommend that you remove your console commands before you go live.
Try Console logging test using console.log You can use sprintf formatting here.

function consoleIntro(){
 var x = "fubar";
 var y = 543;
 console.log("value of x is %s and value of y is %d", x, y);
}

Try Console Error Levels console.info|warn|error

function consoleLogLevels(){
 var a = "This is an info level message";
 var b = "This is a warn level message";
 var c = "This is an error level message";
 console.info(a);
 console.warn(b);
 console.error(c);
}

Try Timer logging console.time|timeEnd

function timeThisTask(){
 console.time("Sample Timer");
 for(x=100000;x>0;x--){}
 console.timeEnd("Sample Timer");
}

Try Error Stack Traces to see stack trace of the errors

function stack1(){
 var d = "fu";var e = "bar";var f = stack2(d,e)
 console.log(f);
}
function stack2(d,e){return stack3(d,e);}
function stack3(d,e){return UndefinedVariable;}

Use the debugger to add breakpoints, debug JavaScript code and step through your code.
There are 3 ways to trigger the debugger:

1. Use the debugger command.
2. Add a breakpoint by clicking on the line number
3. Enable the “Break on All Errors” option for the Script tab.

Try a Deubgger Demo using the debugger command

function debugMe(){
 debugger;
 var g = 1;
 var h = new Date().getMilliseconds();
 while(g < 100){
  g *= 10;
  h -= g;
 }
}

Use the profiler to record detailed statistics on your Script calls and DOM events. This works very much like macros. To manually start profiling click on the profile button in the Console tab. Then try performing some actions on the page. When you are done click on the profile button again. A report is returned which captures the funtions that were called within that time period.
The report output data can be sorted. Own Time tells you how much time each function call took in milliseconds and as a percentage of the total time which can be useful in finding bottlenecks in your code.
Try Manual Profiler test using the manual profile feature

function profileMe(){
 timeThisTask();
 var timerlink = document.getElementById("tabs").
       getElementsByTagName('li')[2].firstChild;
 var typeNode = timerlink.nodeType;
 var nameNode = timerlink.nodeName;
 var valuNode = timerlink.nodeValue;
}

You can also add profilers to your code via the console.profile(“foo”) – console.profileEnd(“foo”) function calls. This can be great when you want to track down events that happen onload.
Try the Coded Profiler using console.profile|profileEnd command

function profiledFunction(){
 console.profile("Test Auto Profiler");
 timeThisTask();
 profileMe();
 console.profileEnd("Test Auto Profiler");
}

You can log calls to a specific function call and see what parameters are being passed to it and how many times it is being called. To do this open the script tab, find your function and right click within it. From the popup menu choose the “log calls to “function name”".

Now whenever that function is called you get a nice message in the console along with the parameter values sent to it.
Try the Logged Function test with logged functions

function callLoggedFunction(){
 for(x=0;x<2;x++){for(y=1;y>0;y--){loggedFuction(x,y);}}
}
function loggedFuction(x,y){
 if(y>x) console.info("y is greater than x");
}

In the HTML tab you can also log events for specific elements. This can be useful when you are creating elements on the fly via the DOM and want to track all the events happening behind the scenes.
The Net tab is quite useful for tracing HTTP request and responses. Network traffic can be filtered by type (HTML, CSS, JS, Images, XmlHttpRequest). The Params tab is very handy and shows you the request parameters in a table format. This is great for tracing your Ajax requests. The issue with this that I found is that once a request is made which leaves the current page you loose the previous pages net events. Maybe a feature for the next version of FireBug?

From the HTML tab you can use the Layout tab to view and edit any element’s offset, margin, border, padding and dimension values on the fly.
In the Style sub tab of the HTML tab you can choose an option to “Show Computed Style” which shows you the final style values of the selected HTML element. Another neat trick is that you can click on any CSS property and edit it inline in real time. You can use the up/down keys and page up/page down keys to change numeric values and see your changes in real time, for example padding etc.