smb를 사용하면 로그를 지저분하게 더럽히는 것들이 있다. 사용에 있어서 전혀 지장은 없지만 뭔가 껄끄러워보이는 것이 찜찜하게 만들고 이유없는 리부팅이나 셧다운에도 신경이 쓰인다.

smb 특성상 linux와 windows의 공통 파일 서버 구성에 사용하는데 windows 데스크톱 환경 때문에 smb가 설정된 linux 서버를 괴롭히게 된다.

smb를 설정하면 자꾸 나오는 에러가 두가지가 프린터와 접근하지 않는 port 문제가 있다.

프린터 메세지
Feb  9 12:10:57 server01 smbd[2945]: [2009/02/09 12:10:57, 0] printing/print_cups.c:cups_connect(69)
Feb  9 12:10:57 server01 smbd[2945]:   Unable to connect to CUPS server localhost:631 - Connection refused
cpus 서비스는 당연히 꺼놓았는데 계속해서 발생하며 요청을 한다. smb에서 프린터 설정을 활성화 시켜서 윈도우의 기본 기능인 사용 가능한 프린터 찾는 것 때문에 자꾸 접근해서 메세지를 쌓게 만든다.

port 관련 오류
Feb 13 09:56:19 server01 smbd[14757]: [2009/02/13 09:56:19, 0] lib/util_sock.c:get_peer_addr(1224)
Feb 13 09:56:19 server01 smbd[14757]:   getpeername failed. Error was Transport endpoint is not connected
Feb 13 09:56:19 server01 smbd[14757]: [2009/02/13 09:56:19, 0] lib/util_sock.c:write_data(562)
Feb 13 09:56:19 server01 smbd[14757]:   write_data: write failure in writing to client 116.126.102.114. Error Connection reset by peer
Feb 13 09:56:19 server01 smbd[14757]: [2009/02/13 09:56:19, 0] lib/util_sock.c:send_smb(761)
Feb 13 09:56:19 server01 smbd[14757]:   Error writing 4 bytes to client. -1. (Connection reset by peer)
smb 서비스를 가동하면 tcp port 139, 445와 udp 137, 138을 열어 놓는다. 사용자가 NBT(NetBIOS over TCP/IP) 기반으로 접근하려면 137, 138, 139로 접근하고 NBT를 꺼놓거나 2000이상은 SMB로 바로 붙어버릴 수 있게 한다. 즉, 98까지는 무조건 NBT 기반이므로 139로 들어오겠지만 2000부터는 445를 사용하는 것이 보통이다. 헌데 여기서 문제는 2000 이상에 NBT를 활성화 시켜놓게 되면 139, 445 모두 접근해서 445를 끊어버린다. 이때 smb 서버에서는 사용자에서 일방적인 접속이 끊어지게 되면서 에러를 발생하게 된다.
2000 이상에서 NetBISO를 설정한 것이기 때문에 어쩔 수 없는 상황이다.
참고) http://www.ntsecurity.nu/papers/port445/

우선 사용하지 않을 설정 부분을 주석 처리 해준다.
[homes]라든지 [printers] 같은 것은 보통 사용하지 않는것이 보통이므로 주석처리한다.
다음으로 [global] 부분의 printing operation 부분을 주석 처리하고 다음을 추가 한다.

    load printers = no
    show add printer wizard = no
    printing = none
    printcap name = /dev/null
    disable spoolss = yes

마지막으로

[global] 에서 network 관련 부분에

    smb ports = 139

추가한다.

기본적인 설정 및 계정 관련, 암호화 등은 범위에 벗어나므로 찾아보시기 바란다.

'Liunx > LAMP' 카테고리의 다른 글

mod_gzip, mod_deflate  (0) 2008.01.10

mod_gzip, mod_deflate

Liunx/LAMP 2008. 1. 10. 16:40 posted by deneb

웹서버의 스트리밍데이타를 압축해서 보내자는 말이 나왔다.

당연히 mod_gzip을 찾아보고 적용 시키는 중에 죽어도 컴파일이 안되는 것이 발생해서...

그럼 php에서 한다고 생각해서 php 모듈을 찾다가 보니 그다지 뾰족한 것이 없었다.

더욱 찬찬히 찾아보니...

웬걸

삽질이었다.

Apache2 이상에서는 mod_gzip 대신에 mod_deflate에서 압축을 담당하는 것이었다.

적용을 해보자

1) httpd.conf
LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module modules/mod_headers.so
가 있는지 확인하자.

2) 적용할 디렉토리를 찾는다.
vhost를 사용하지 않으면 httpd.conf에 있을 것이고
vhost 사용시에는 각 도메인의 디렉토리를 찾는다.

2-1) 모두 압축하고 하지 않을 필터를 설정
<Directory 경로~>
SetOutputFilter DEFLATE
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary
Header append Vary User-Agent env=!dont-vary
</Directory>

2-2) 압축할 필터를 설정
<Directory 경로~>
AddOutputFilterByType DEFLATE text/html text/plain text/css text/javascript text/xml application/x-javascript
</Directory>

3) apachectl -k restart
적용 완료 -_-


확인은 httpwatch 같은 것으로 패킷캡쳐 해보면 안다.

참고 site

http://httpd.apache.org/docs-2.0/mod/mod_deflate.html

'Liunx > LAMP' 카테고리의 다른 글

/var/log/message 에 SMB관련 에러 메세지 발생시 설정  (51) 2009.02.13

출처 : http://tunelinux.pe.kr/gboard/bbs/board.php?bo_table=tip&wr_id=75&page=

RHN 에 지식기반정보가 있습니다.
rhn 등록되어있는 사용자만이 접속할 수 있지요.

한번 테스팅해볼만한 내용이네요.
문제해결을 위하여.

그리고 시스템의 정보를 수집하기 위한 sysreport 라는 프로그램이 있습니다. rhn등을 이용하여 설치하면 되고 위 명령만 치면 시스템의 주요정보를 모읍니다.

Solution Found
Issue:
My system had a kernel panic, an oops message, or is freezing for no apparent reason. How can I find out what is causing this?
Resolution:         Last update: 08-17-04
Resolving a kernel panic or a kernel oops is not a simple task. First off, in order for Red Hat to understand the cause of this, we will need to see the panic or oops message in its entirety. Below you will find our \"Profiling\" document, it contains the information that Red Hat requires in order to best troubleshoot a kernel panic or kernel oops related to a system crash.

We do recommend that you are running the latest kernel available for your release version and that have your system completely updated.

To further debug this problem we will need the following information:
The output from the following commands:

    * sysreport
    * lspci -vv
    * lsmod
    * cat /proc/meminfo
    * cat /proc/cpuinfo
    * uname -a


Please note, sysreport is an application that may not be installed on your system. If you do not have it installed, please install the sysreport RPM in one of the following ways:

    * Run: up2date sysreport if your system is registered with RHN, this will download and install the package for you.
    * Locate the sysreport package on your installation CD's and install the package with: rpm -ivh sysreport-version#.rpm - where version# will match the files version number on your installation CD.


If possible, please run these commands when the slow down is occuring, or as close as possible to a reproduceable crash. That being said, we do recognize that this is not always possible, but the information is still needed.

    * OOPS messages:

      If your machine crashes with an OOPS message, similar to the following:

Unable to handle kernel NULL pointer dereference at virtual address
00000018
*pde = 0f992001
Oops: 0000
CPU:    1
EIP:    0010:[]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010207
eax: 00000000   ebx: c87a1ed0   ecx: c02de5e0   edx: f3de3b00
esi: c87a1eb4   edi: 00000000   ebp: 00000007   esp: c3f5bfa0
ds: 0018   es: 0018   ss: 0018
Process kswapd (pid: 11, stackpage=c3f5b000)
Stack: 00000000 fffffe5d 00000245 00085992 00000001 00000000 000000c0 000000c0
       0008e000 c0136c51 000000c0 00000000 c3f5a000 00000006 c0136ce5 000000c0
       00000000 00010f00 c3ff1fb8 c0105000 c0105866 00000000 c0136c90 c02f5fc0
Call Trace: [] do_try_to_free_pages [kernel] 0x11
[] kswapd [kernel] 0x55
[] stext [kernel] 0x0
[] kernel_thread [kernel] 0x26
[] kswapd [kernel] 0x0
Code: f7 40 18 06 00 00 00 75 f0 8b 40 28 39 d0 75 f0 31 d2 85 d2


>>EIP; c0136177    <=====

Trace; c0136c51
Trace; c0136ce5
Trace; c0105000 <_stext+0/0>
Trace; c0105866
Trace; c0136c90
Code;  c0136177
00000000 <_EIP>:
Code;  c0136177    <=====
   0:   f7 40 18 06 00 00 00      testl  $0x6,0x18(%eax)   <=====
Code;  c013617e
   7:   75 f0                     jne    fffffff9 <_EIP+0xfffffff9>
c0136170
Code;  c0136180
   9:   8b 40 28                  mov    0x28(%eax),%eax
Code;  c0136183
   c:   39 d0                     cmp    %edx,%eax
Code;  c0136185
   e:   75 f0                     jne    0 <_EIP>
Code;  c0136187
  10:   31 d2                     xor    %edx,%edx
Code;  c0136189
  12:   85 d2                     test   %edx,%edx


      We will need the full output from the OOPS message, which can be obtained in one of the following ways:

          o Copied down by hand (or from a digital picture), please remember we need the complete message and that this may sometimes be the only way to get the oops message.
          o Setting up a serial console to capture the message. This can be accomplished by connecting a null modem cable to the serial port of the machine and adding:

            console=ttyS0,115200 console=tty0

            to either the kernel line of grub or in an \"append=\" statement for lilo. Once this is done, on the other machine the null modem is attached to, run a terminal emulator such as \"minicom\" (linux) or \"hyperterminal\" (windows).

    * Mysterious Hangs, Freezes and Slowdowns:

      For hangs and freezes, we would like you to capture some information by enabling the sysrq key. This can be enabled by editing the file /etc/sysctl.conf and changing the line to read:

      kernel.sysrq = 1

      Enable it immediately by saving the file and running:

      # sysctl -p

      Once this is enabled, we will need the output from the following key combinations:
          o alt-sysrq-t
          o alt-sysrq-p
          o alt-sysrq-m
      * Please note that sysrq is the PrintScreen key.

      Please run alt-sysrq-p multiple times so that we can be sure to get output from all CPUs on the machine. Also, run alt-sysrq-m last as it has a possiblity of locking the box up harder then it already is. You may wish to use a serial console to capture the information. You will also want to ensure that we have at least 1 alt-sysrq-p from each CPU, denoted by a CPU: # line in the output. Note the first CPU is number 0.

    * Slowdowns:

      For general slowdowns we will first need to know the following:
          o What kind of load is the box under?
          o Are you running anything to produce this load?
          o If you stop running whatever may cause the load, does the slowness immediately go away?

            Next, we would like you to follow the following steps to gather some data for our engineers:

            1. Enable kernel profiling by turning on nmi_watchdog and allocating the kernel profile buffer. For example, add the following two items to the \"kernel\" line of /boot/grub/grub.conf (using grub):

                  profile=2 nmi_watchdog=1

            as in the following example:

                  kernel /vmlinuz-2.4.9-e.27smp ro profile=2 nmi_watchdog=1

            If using LILO, add the following to the global section (before the first image= line) of lilo.conf:
                  append=\"profile=2 nmi_watchdog=1\"
            and run lilo -v as root.
            Now you should be able to reboot.

            2. Create a shell script containing the following lines:

#!/bin/sh
while /bin/true; do
  echo;date
  /usr/sbin/readprofile -v -m /boot/System.map | sort -nr +2 | head -15
  /usr/sbin/readprofile -r
  sleep 5
done

          o Make the system demonstrate the aberrant behavior.
          o Run the following three commands simultaneously:

                  Execute the readprofile shell script above, redirecting its output to a file.
                  Execute vmstat 5 and redirect its output to a second file.
                  Execute top -d5 and redirect its output to a third file.

          o Attach the output files (preferably in gzip'd tar file format) to a web ticket that either you or a Red Hat Engineer has opened.


      You can open a web ticket with Red Hat support by logging into your www.redhat.com account in the Support and Docs section and selecting the Web Support button located under the \"Active Support Entitlements\" section.