나만의 세상~!

참고 하세요

http://www.youtube.com/watch?v=Bd6PObD0Arw

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 삐꾸강아쥐

http://linux.dell.com/wiki/index.php/Products/HA/DellRedHatHALinuxCluster/Cluster#Configure_iDRAC6_Fencing

RHEL 5.4 기준 RHCS 에서 fence device 를 사용할때 dell drac6 를 기본적으론 지원을 하지 않는다.

이럴경우 drac6로 사용하기 위한 메뉴얼

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 삐꾸강아쥐

site : http://ftp.genotec.ch/pub/RedHat/5.2/x86_64/os/RELEASE-NOTES-ko.html

raw 장치 맵핑

raw 장치 인터페이스는 Red Hat Enterprise Linux 5에서 사용되지 않습니다; 현재 raw 장치 맵핑은 udev 규칙을 통해 설정됩니다.

raw 장치 맵핑을 설정하기 위해, 다음의 포맷에서 /etc/udev/rules.d/60-raw.rules로 알맞은 항목을 추가하시기 바랍니다:

• 
  

  장치명:

  
  

  ACTION=="add", KERNEL="<device name>", RUN+="raw /dev/raw/rawX %N"
  

  
  
• 
  

  주 번호/ 부 번호:

  
  

  ACTION=="add", ENV{MAJOR}="A", ENV{MINOR}="B", RUN+="raw /dev/raw/rawX %M %m"
  

  
  

여기서 <device name>은 바인드해야 하는 장치명으로 대체합니다 (예: /dev/sda1). "A"와 "B"는 바인드해야 하는 장치의 주 번호와 부 번호로, 여기서 X는 시스템에서 사용하고자 하는 raw 장치 번호로 대체합니다.

기존에 있는 용량이 큰 /etc/sysconfig/rawdevices 파일을 갖고 계실 경우, 이를 다음과 같은 스크립트로 변경합니다:

#!/bin/sh

grep -v "^ *#" /etc/sysconfig/rawdevices | grep -v "^$" | while read dev major minor ; do
        if [ -z "$minor" ]; then
                echo "ACTION==\"add\", KERNEL==\"${major##/dev/}\", RUN+=\"/usr/bin/raw $dev %N\""
        else
                echo "ACTION==\"add\", ENV{MAJOR}==\"$major\", ENV{MINOR}==\"$minor\", RUN+=\"/usr/bin/raw $dev %M %m\""
        fi
done

ex)
제공 : 회사의 blackssam 님


RHEL5에서 Raw 디바이스 설정하는 방법입니다.

raw device 만들때 udev에 설정을 추가하고 반드시 수동으로 파일을 생성해야 함.
/etc/udev/rules.d/60-raw.rules
ACTION=="add", KERNEL=="sddlmck2", RUN+="/bin/raw /dev/raw/raw1 %N"
ACTION=="add", KERNEL=="sddlmck3", RUN+="/bin/raw /dev/raw/raw2 %N"
ACTION=="add", KERNEL=="sddlmck5", RUN+="/bin/raw /dev/raw/raw3 %N"
ACTION=="add", KERNEL=="sddlmck6", RUN+="/bin/raw /dev/raw/raw4 %N"
ACTION=="add", KERNEL=="sddlmck7", RUN+="/bin/raw /dev/raw/raw5 %N"



/etc/udev/rules.d/50-udev.rules ==> permission 설정.(항목 사이는 반드시
tab으로)
KERNEL=="raw1", OWNER="oracle", GROUP="dba", MODE="0640"
KERNEL=="raw2", OWNER="oracle", GROUP="dba", MODE="0640"
KERNEL=="raw3", OWNER="oracle", GROUP="dba", MODE="0640"
KERNEL=="raw4", OWNER="oracle", GROUP="dba", MODE="0640"
KERNEL=="raw5", OWNER="oracle", GROUP="dba", MODE="0640"

또는


# cat /etc/udev/rules.d/60-raw.rules
ACTION=="add", KERNEL=="raw*", OWNER=="root", GROUP=="disk", MODE=="0660"
ACTION=="add", KERNEL=="raw2", OWNER=="test", GROUP=="test", MODE=="0660"

처럼 해도 된다.

추가 : 091230

RHEL 5.4 에서 /etc/sysconfig/rawdevices 파일이 다시 생겼습니다.

rawdevices 에 내용 입력 후

# cat /etc/udev/rules.d/60-raw.rules
ACTION=="add", KERNEL=="raw*", OWNER=="root", GROUP=="disk", MODE=="0660"
ACTION=="add", KERNEL=="raw2", OWNER=="test", GROUP=="test", MODE=="0660"

Owner Ship 을 주면 된다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 삐꾸강아쥐

출처 : http://rhn.redhat.com (errata)

RHBA-2007:1012 - Bug Fix Advisory
정보
 패키지
 영향을 받은 시스템
 
개요
telnet-server bug fix update

발행된 날짜: 07. 11. 15
업데이트된 날짜: 07. 11. 15

주제
Updated telnet-server packages that fixe a bug are now available.

설명
Telnet is a popular protocol for logging in to remote systems over the
Internet. The telnet-server package includes a telnet daemon that
supports remote logins into the host machine. The telnet daemon is
disabled by default.

The telnet daemon refused connections when the reverse records for the
host you were connecting to did not exist, for example, when configured
nameservers were unavailable, and the host you were connecting to was not
in "/etc/hosts". Telnet sessions would terminate with a "Temporary failure
in name resolution: Illegal seek" error.

Users of the telnet-server packages are advised to upgrade to these
updated packages, which resolve this issue.

해결책
Before applying this update, make sure that all previously-released
errata relevant to your system have been applied.

This update is available via Red Hat Network. Details on how to use
the Red Hat Network to apply this update are available at
http://kbase.redhat.com/faq/FAQ_58_10188

영향을 받은 채널
Red Hat Enterprise Linux (v. 5 64-bit IBM System z)
Red Hat Enterprise Linux (v. 5 for 32-bit x86)
Red Hat Enterprise Linux (v. 5 for 64-bit IBM POWER)
Red Hat Enterprise Linux (v. 5 for 64-bit Itanium)
Red Hat Enterprise Linux (v. 5 for 64-bit x86_64)
Red Hat Enterprise Linux Desktop (v. 5 for 32-bit x86)
Red Hat Enterprise Linux Desktop (v. 5 for 64-bit x86_64)

해결방안 :

https://bugzilla.redhat.com/show_bug.cgi?id=253392

수정
telnetd refuses connections if nameserver(s) down

키워드
dns, host

CVEs
(없음)

OVAL
(없음)

참조 정보
(없음)

알림
(없음)

에레타 내용
추가 : http://rhn.redhat.com/errata/RHBA-2007-1012.html

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 삐꾸강아쥐

yum install pidgin
Loading "rhnplugin" plugin
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
rhel-i386-server-5        100% |=========================| 1.4 kB    00:00     
rhel-i386-server-vt-5     100% |=========================| 1.4 kB    00:00     
rhn-tools-rhel-i386-serve 100% |=========================| 1.2 kB    00:00     
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package pidgin.i386 0:2.2.2-0.el5 set to be updated
--> Running transaction check
--> Processing Dependency: perl(Purple) for package: pidgin
--> Processing Dependency: libpurple = 2.2.2 for package: pidgin
--> Processing Dependency: libpurple.so.0 for package: pidgin
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package libpurple.i386 0:2.2.2-0.el5 set to be updated
--> Running transaction check
--> Processing Dependency: libsilcclient-1.0.so.1 for package: libpurple
--> Processing Dependency: libsilc-1.0.so.2 for package: libpurple
--> Finished Dependency Resolution
Error: Missing Dependency: libsilcclient-1.0.so.1 is needed by package libpurple
Error: Missing Dependency: libsilc-1.0.so.2 is needed by package libpurple

## 애러 내용 libsilc관련 의존성 애러

libsilc-1.0.2-2.fc6.src.rpm 설치하면 해결됨. ( Desktop 버전에 있음 )


2008.07.31 추가
nateon plugin 설치시 발생하는
You must have the GLib 2.0 development headers installed to build.
문제는...

glibc2 버전이 설치 되어 있다는 가정하에 libpurple-devel 를 설치 하면 해결 된다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 삐꾸강아쥐

출처 : RHEL5=/usr/share/doc/kexec-tools-(version)/./kexec-kdump-howto.txt




Kexec/Kdump HOWTO




Introduction




Kexec and kdump are new features in the 2.6 mainstream kernel. These features


are included in Red Hat Enterprise Linux 5. The purpose of these features


is to ensure faster boot up and creation of reliable kernel vmcores for


diagnostic purposes.




Overview




Kexec




Kexec is a fastboot mechanism which allows booting a Linux kernel from the


context of already running kernel without going through BIOS. BIOS can be very


time consuming especially on the big servers with lots of peripherals. This can


save a lot of time for developers who end up booting a machine numerous times.




Kdump




Kdump is a new kernel crash dumping mechanism and is very reliable because


the crash dump is captured from the context of a freshly booted kernel and


not from the context of the crashed kernel. Kdump uses kexec to boot into


a second kernel whenever system crashes. This second kernel, often called


a capture kernel, boots with very little memory and captures the dump image.




The first kernel reserves a section of memory that the second kernel uses


to boot. Kexec enables booting the capture kernel without going through BIOS


hence contents of first kernel's memory are preserved, which is essentially


the kernel crash dump.




Kdump is supported on the i686, x86_64, ia64 and ppc64 platforms. The


standard kernel and capture kernel are one in the same on i686, x86_64


and ia64, while ppc64 requires a separate capture kernel (provided by the


kernel-kdump package) at this time.




If you're reading this document, you should already have kexec-tools


installed. If not, you install it via the following command:




    # yum install kexec-tools




Now load a kernel with kexec:




    # kver=`uname -r` # kexec -l /boot/vmlinuz-$kver


    --initrd=/boot/initrd-$kver.img \


        --command-line="`cat /proc/cmdline`"




NOTE: The above will boot you back into the kernel you're currently running,


if you want to load a different kernel, substitute it in place of `uname -r`.




Now reboot your system, taking note that it should bypass the BIOS:




    # reboot






How to configure kdump:




Again, we assume if you're reading this document, you should already have


kexec-tools installed. If not, you install it via the following command:




    # yum install kexec-tools




If you're on ppc64, you'll first need to install the kernel-kdump package:




    # yum install kernel-kdump




To be able to do much of anything interesting in the way of debug analysis,


you'll also need to install the kernel-debuginfo package, of the same arch


as your running kernel, and the crash utility:




    # yum --enablerepo=\*debuginfo install kernel-debuginfo.$(uname -m) crash




Next up, we need to modify some boot parameters to reserve a chunk of memory


for the capture kernel. For i686 and x86_64, edit /etc/grub.conf, and append


"crashkernel=128M@16M" to the end of your kernel line. Similarly, append


the same to the append line in /etc/yaboot.conf for ppc64, followed by a


/sbin/ybin to load the new configuration (not needed for grub). On ia64,


edit /etc/elilo.conf, adding "crashkernel=256M@256M" to the append line for


your kernel. Note that the X@Y values are such that X = the amount of memory


to reserve for the capture kernel and Y = the offset into memory at which


that reservation should start.




Examples:


 # cat /etc/grub.conf


# grub.conf generated by anaconda # # Note that you do not have to rerun grub


after making changes to this file # NOTICE:  You have a /boot partition.


This means that #          all kernel and initrd paths are relative to


/boot/, eg.  #          root (hd0,0) #          kernel /vmlinuz-version ro


root=/dev/VolGroup00/root #          initrd /initrd-version.img #boot=/dev/hda


default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title


Red Hat Enterprise Linux (2.6.17-1.2621.el5)


        root (hd0,0) kernel /vmlinuz-2.6.17-1.2621.el5 ro


        root=/dev/VolGroup00/root crashkernel=128M@16M initrd


        /initrd-2.6.17-1.2621.el5.img






 # cat /etc/yaboot.conf


# yaboot.conf generated by anaconda




boot=/dev/sda1 init-message=Welcome to Red Hat Enterprise Linux!\nHit <TAB>


for boot options




partition=2 timeout=80 install=/usr/lib/yaboot/yaboot delay=5 enablecdboot


enableofboot enablenetboot nonvram fstype=raw




image=/vmlinuz-2.6.17-1.2621.el5


        label=linux read-only initrd=/initrd-2.6.17-1.2621.el5.img


        append="root=LABEL=/ crashkernel=128M@16M"






 # cat /etc/elilo.conf


prompt timeout=20 default=2.6.17-1.2621.el5 relocatable




image=vmlinuz-2.6.17-1.2621.el5


        label=2.6.17-1.2621.el5 initrd=initrd-2.6.17-1.2621.el5.img read-only


        append="-- root=LABEL=/ crashkernel=256M@256M"






After making said changes, reboot your system, so that the X MB of memory


starting Y MB into your memory is left untouched by the normal system,


reserved for the capture kernel. Take note that the output of 'free -m' will


show X MB less memory than without this parameter, which is expected. You


may be able to get by with less than 128M, but testing with only 64M has


proven unreliable of late. On ia64, as much as 512M may be required.




Now that you've got that reserved memory region set up, you want to turn on


the kdump init script:




    # chkconfig kdump on




Then, start up kdump as well:




    # service kdump start




This should load your kernel-kdump image via kexec, leaving the system ready


to capture a vmcore upon crashing. To test this out, you can force-crash


your system by echo'ing a c into /proc/sysrq-trigger:




    # echo c > /proc/sysrq-trigger




You should see some panic output, followed by the system restarting into


the kdump kernel. When the boot process gets to the point where it starts


the kdump service, your vmcore should be copied out to disk (by default,


in /var/crash/<YYYY-MM-DD-HH:MM>/vmcore), then the system rebooted back into


your normal kernel.




Once back to your normal kernel, you can use the previously installed crash


kernel in conjunction with the previously installed kernel-debuginfo to


perform postmortem analysis:




    # crash /usr/lib/debug/lib/modules/2.6.17-1.2621.el5/vmlinux


    /var/crash/2006-08-23-15:34/vmcore




    crash> bt




and so on...






Advanced Setups:




In addition to being able to capture a vmcore to your system's local file


system, kdump can be configured to capture a vmcore to a number of other


locations, including a raw disk partition, a dedicated file system, an NFS


mounted file system, or a remote system via ssh/scp. Additional options


exist for specifying the relative path under which the dump is captured,


what to do if the capture fails, and for compressing and filtering the dump


(so as to produce smaller, more manageable, vmcore files).




In theory, dumping to a location other than the local file system should be


safer than kdump's default setup, as its possible the default setup will try


dumping to a file system that has become corrupted. The raw disk partition and


dedicated file system options allow you to still dump to the local system,


but without having to remount your possibly corrupted file system(s),


thereby decreasing the chance a vmcore won't be captured. Dumping to an


NFS server or remote system via ssh/scp also has this advantage, as well


as allowing for the centralization of vmcore files, should you have several


systems from which you'd like to obtain vmcore files. Of course, note that


these configurations could present problems if your network is unreliable.




Advanced setups are configured via modifications to /etc/kdump.conf,


which out of the box, is fairly well documented itself. Any alterations to


/etc/kdump.conf should be followed by a restart of the kdump service, so


the changes can be incorporated in the kdump initrd. Restarting the kdump


service is as simple as '/sbin/service kdump restart'.






Note that kdump.conf is used as a configuration mechanism for capturing dump


files from the initramfs (in the interests of safety), the root file system is


mounted, and the init process is started, only as a last resort if the


initramfs fails to capture the vmcore.  As such, configuration made in


/etc/kdump.conf is only applicable to capture recorded in the initramfs.  If


for any reason the init process is started on the root file system, only a


simple copying of the vmcore from /proc/vmcore to /var/crash/$DATE/vmcore will


be preformed.




Raw partition




Raw partition dumping requires that a disk partition in the system, at least


as large as the amount of memory in the system, be left unformatted. Assuming


/dev/sda5 is left unformatted, kdump.conf can be configured with 'raw


/dev/sda5', and the vmcore file will be copied via dd directly onto partition


/dev/sda5. Restart the kdump service via '/sbin/service kdump restart'


to commit this change to your kdump initrd.




Dedicated file system




Similar to raw partition dumping, you can format a partition with the file


system of your choice, leaving it unmounted during normal operation. Again,


it should be at least as large as the amount of memory in the system. Assuming


/dev/sda3 has been formatted ext3, specify 'ext3 /dev/sda3' in kdump.conf,


and a vmcore file will be copied onto the file system after it has been


mounted. Dumping to a dedicated partition has the advantage that you can dump


multiple vmcores to the file system, space permitting, without overwriting


previous ones, as would be the case in a raw partition setup. Restart the


kdump service via '/sbin/service kdump restart' to commit this change to


your kdump initrd.  Note that for local file systems ext3 and ext2 are


supported as dumpable targets.  Kdump will not prevent you from specifying


other filesystems, and they will most likely work, but their operation


cannot be guaranteed.  for instance specifying a vfat filesystem or msdos


filesystem will result in a successful load of the kdump service, but during


crash recovery, the dump will fail if the system has more than 2GB of memory


(since vfat and msdos filesystems do not support more than 2GB files).


Be careful of your filesystem selection when using this target.




NFS mount




Dumping over NFS requires an NFS server configured to export a file system


with full read/write access for the root user. All operations done within


the kdump initial ramdisk are done as root, and to write out a vmcore file,


we obviously must be able to write to the NFS mount. Configuring an NFS


server is outside the scope of this document, but either the no_root_squash


or anonuid options on the NFS server side are likely of interest to permit


the kdump initrd operations write to the NFS mount as root.




Assuming your're exporting /dump on the machine nfs-server.example.com,


once the mount is properly configured, specify it in kdump.conf, via 'net


nfs-server.example.com:/dump'. The server portion can be specified either


by host name or IP address. Following a system crash, the kdump initrd will


mount the NFS mount and copy out the vmcore to your NFS server. Restart the


kdump service via '/sbin/service kdump restart' to commit this change to


your kdump initrd.




Remote system via ssh/scp




Dumping over ssh/scp requires setting up passwordless ssh keys for every


machine you wish to have dump via this method. First up, configure kdump.conf


for ssh/scp dumping, adding a config line of 'net user@server', where 'user'


can be any user on the target system you choose, and 'server' is the host


name or IP address of the target system. Using a dedicated, restricted user


account on the target system is recommended, as there will be keyless ssh


access to this account.




Once kdump.conf is appropriately configured, issue the command '/sbin/service


kdump propagate' to automatically set up the ssh host keys and transmit


the necessary bits to the target server. You'll have to type in 'yes'


to accept the host key for your targer server if this is the first time


you've connected to it, and then input the target system user's password


to send over the necessary ssh key file. Restart the kdump service via


'/sbin/service kdump restart' to commit this change to your kdump initrd.




Path




By default, local file system vmcore files are written to /var/crash/%DATE


on the local system, ssh/scp dumps to /var/crash/%HOST-%DATE on the target


system, dedicated file system partition dumps to ./var/crash/%DATE, and


NFS dumps to ./var/crash/%HOST-%DATE, the latter two both relative to


their respective mount points within the kdump initrd (usually /mnt). The


'/var/crash' portion of the path can be overridden using kdump.conf's 'path'


variable, should you wish to write the vmcore out to a different location. For


example, 'path /data/coredumps' would lead to vmcore files being written to


/data/coredumps/%DATE if you were dumping to your local file system.  Note


that the path option is ingnored if your kdump configuration results in the


core being saved from the initscripts in the root filesystem.




Default action




By default, if a configured dump method fails, the kdump initrd falls back


to trying to dump to the local file system (i.e., into the file system(s)


you would have mounted under normal system operation). The system always


reboots following an attempted dump to your local file system, regardless


of success or failure.




However, for any of the advanced methods, if the dump fails, you can configure


the kdump initrd to skip trying to dump to the local file system, either


immediately rebooting ('default reboot') or dropping your to a shell within


the initrd ('default shell'), from which you could try to capture the vmcore


manually. Again, if the 'default' parameter is unset, a local file system


dump will be attempted, then the system will reboot.




Compression and filtering




The 'core_collector' parameter in kdump.conf allows you to specify a custom


dump capture method. The most common alternate method is makedumpfile, which


is a dump filtering and compression utility provided with kexec-tools. On


some architectures, it can drastically reduce the size of your vmcore files,


which becomes very useful on systems with large amounts of memory.




A typical setup is 'core_collector makedumpfile -c', but check the output of


'/sbin/makedumpfile --help' for a list of all available options (-i and -g


don't need to be specified, they're automatically taken care of). Note that


use of makedumpfile requires that the kernel-debuginfo package corresponding


with your running kernel be installed. Also, note that for technical reasons,


makedumpfile cannot be used with ssh/scp or raw dumps.




Also note that makedumpfile is only used from the initramfs.  Saving a


core from the initscript in the root filesystem is considered a last ditch


effort, only used when the initramfs has failed to save the core properly.


As such only the cp utiltiy is used in the initscripts.  The implication


here is that in order to use makedumpfile as your core collector, you must


specify a dump target in /etc/kdump.conf.




Caveats:




Console frame-buffers and X are not properly supported. If you typically run


with something along the lines of "vga=791" in your kernel config line or


have X running, console video will be garbled when a kernel is booted via


kexec. Note that the kdump kernel should still be able to create a dump,


and when the system reboots, video should be restored to normal.






Notes on RHEL5 configuration:




The RHEL5 kexec-utils package contains two extra configuration files:




/etc/sysconfig/kdump


This file allows you to specify an alternate kernel to boot in the


event of a panic (other than the kernel running at the moment), and allows you


to override or append options on the kernel command line.  It also alows you


to pass extra options to the kexec utility when the kdump service is starting.


See documentation in the template kdump sysconfig file for exact usage




/etc/kdump.conf


This file allows you to configure how kdump will record your core


file.  Unlike the stock version of kdump, the RHEL5 version of kdump attempts


to record your vmcore file from the initramfs, so as to still function


properly in the event that your root file system is corrupted and unmountable.


This file is interrogated on kdump service start and is used to populate the


initramfs for the kdump kernel with the appropriate data and utilities to copy


your core file to the desired location.  See documentation in /etc/kdump.conf


for available config directives and targets.  Note especially the ifc option.


kdump will attempt to determine which network interface to use when dumping to


a remote server, but due to the possibility of interface renaming, or alternate


module load strategies, the interface name may change in the kdump kernel.


This option is used to override that guess, so that the appropriate interface


will be activated in the kdump kernel.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 삐꾸강아쥐

CentOS5 맛보기로 살짝 올려 봅니다...^^

VMWare 로 설치 하였으며 커널은 2.6.18-8.el5 가 설치되어 있으며

^^ 아직 많이 사용해 보지 않아서 파폭으로 제 블로그 한번 띄워 봤습니다...

뭐... 더 사용하게 되면 더 좋은 스샷 올리겠습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 삐꾸강아쥐

레드헷에서 드디어 RHEL5를 출시 하는구나...^^;;
관련 행사 내용 입니다. 관심 있는분 참석해 보세요~!
자세한 내용은 : http://www.kr.redhat.com/mktg/solutionsseminar2007/

• 일시 : 2007년 5월 2일 오후 1시~ 6시
  
• 장소 : 코엑스 컨벤션 홀 그랜드 볼룸

AGENDA

Track 1	Track 2
13:00~13:30	등록
13:30~13:40	Key note speech
13:40~14:20	Red Hat Enterprise Linux 5 feature & Benefits
14:20~15:50	오픈소스 가상화솔루션 소개 및 데모 OS 가상화 VS Storage 가상화
15:50~16:10	부스 관람 및 Coffee Break
16:10~16:40	RHEL 기반의 메일 솔루션 -테라스테크놀로지	Dell 서버 기반의 UNIX to Linux 마이그레이션
16:45~17:30	JBoss SOA Solution	효율적인 서버 운영을 위한 IBM 가상화 솔루션

GIVEAWAY

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 삐꾸강아쥐