pgsql 외부접속 설정.

출처 :


PostgreSQL은 IP를 기반으로 한 접근 제어를 통해 보안 증대 효과를 보고있습니다.

최초 설치시 localhost에서만 접근만을 허용하기 때문에 어떠한 원격 접속이 불가합니다.

때문에 우리가 사용하고 있는 IP를 허용해주는 설정이 필요합니다.

이 설정을 수행하지 않고 접속을 시도할 경우 아래와 같은 Error가 발생합니다.

1. pg_hba.conf file 수정

■ 하나의 IP / IP 대역 허용

<root@linux># vi /etc/postgresql/9.1/main/pg_hba.conf
host    all             all             md5host    all             all              md5

위 설정은, 192.168.0.X/24 대역의 모든 User가 모든 DB에 접근이 가능하며, IP의 모든 User가 모든 DB에 접근이 가능하다는 설정입니다.

참고로 /24는 Subnetmask을 의미합니다.
(은 11111111.11111111.11111111.00000000이므로 24bit이기 때문입니다.)

■ 모든 IP / IP 대역 허용

위와 같이 설정할 경우, Access할 수 있는 IP를 일일히 입력해줘야 된다는 번거로움이 있습니다.

모든 IP를 허용하고자 할 경우, 아래 내용을 /etc/postgresql/9.1/main/pg_hba.conf에 추가해주시면 됩니다.


host    all             all              md5

2. Service restart

설정 값 변경을 적용시키기 위해 Service를 재시작합니다.
<root@linux># /etc/init.d/posgresql restart
* Restarting PostgreSQL 9.1 database server                       [ OK ]

3. postgres.conf 수정

/etc/postgresql/9.1/main/postgresql.conf file을 열어, ‘listen_address’ 값을 변경합니다.

<root@linux># vi /etc/postgresql/9.1/main/postgresql.conf
listen_addresses = ‘*’
4. PostgreSQL 원격지 접속

윈도우에서 CommandLine 정보 얻어오기.(ps -ef | grep for window)

=========== Command ======================
wmic process where “name=’java.exe'” get ProcessID, Commandline /format:list

=========== OUTPUT ======================
CommandLine=”C:\Program Files\Java\jdk1.7.0_75\bin\javaw.exe” “-Dcatalina.base=D:\Workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0” “-Dcatalina.home=D:\DevelopmentEnv\apache-tomcat-7.0.47” “-Dwtp.deploy=D:\Workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps” “-Djava.endorsed.dirs=D:\DevelopmentEnv\apache-tomcat-7.0.47\endorsed” -Dfile.encoding=MS949 -classpath “D:\DevelopmentEnv\apache-tomcat-7.0.47\bin\bootstrap.jar;D:\DevelopmentEnv\apache-tomcat-7.0.47\bin\tomcat-juli.jar;C:\Program Files\Java\jdk1.7.0_75\lib\tools.jar” org.apache.catalina.startup.Bootstrap start

Disable rp_filter on unix

Sometimes in a more complicated network setups you want to disable rp_filtering.

For a good explanation of what rp_filter is and why it is enabled see this excellent slashroot article here.

I came across a situation where one box had two NICs:

# grep -Ev '^#.*$' /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth1
iface eth1 inet static

auto eth2
iface eth2 inet static
up route add default gw

From another box that was in the same range I could only access this machine over its ip address. When I tried a ping, curl, wget, ssh, telnet or whatever to I got nothing.

A tcpdump on this box showed that packets on the interface were received but my machine had trouble sending the return packets causing the above described behaviour. You get; Nothing.

And whenever I tried to access this box from a machine in the network I got the same behaviour but with the ip.

The routing table on this box looks like the following:

# ip route dev eth1  proto kernel  scope link  src dev eth2  proto kernel  scope link  src 
default via dev eth2 
default via dev eth1  metric 100

Since you cannot have two default routes the kernel tries to sent packets back over the wrong interface.

I solved this by disabling reverse path filtering.

To get your current kernel configuration run:

sysctl -a | grep \\.rp_filter

To enable rp_filtering (persisted up until the next reboot)

sysctl -w net.ipv4.conf.all.rp_filter=1
sysctl -w net.ipv4.conf.default.rp_filter=1
sysctl -w net.ipv4.conf.lo.rp_filter=1

# Replace eth1 and eth2 with your interface names
sysctl -w net.ipv4.conf.eth2.rp_filter=1
sysctl -w net.ipv4.conf.eth1.rp_filter=1

To disable rp_filtering (persisted up until the next reboot)

sysctl -w net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.conf.default.rp_filter=0
sysctl -w net.ipv4.conf.lo.rp_filter=0

# Replace eth1 and eth2 with your interface names
sysctl -w net.ipv4.conf.eth2.rp_filter=0
sysctl -w net.ipv4.conf.eth1.rp_filter=0

If you want to disable rp_filtering permanently create a file90-disable-rp_filter.conf inside /etc/sysctl.d with the following contents:

# cat /etc/sysctl.d/90-disable-rp_filter.conf 

소스: Disable rp_filter on unix

Useful :nth-child Recipes | CSS-Tricks

Select Only the Fifth Element

li:nth-child(5) {
    color: green;   

To select the first element, you can use :first-child, or I bet you can guess how to alter the above to do it as well.

Select All But The First Five

li:nth-child(n+6) {
    color: green;   

If there were more than 10 elements here, it would select all of them beyond 5.

Select Only The First Five

li:nth-child(-n+5) {
    color: green;   

Select Every Fourth, Starting At The First

li:nth-child(4n-7) {  /* or 4n+1 */
    color: green;   

Select Only Odd or Even

li:nth-child(odd) {
    color: green;   

li:nth-child(even) {
    color: green;   

Select The Last Element

li:last-child {
    color: green;

Selects the 10th because we have 10 elements here, but if there was 8 it would select the 8th, or if there were 1,290 it would select the 1,290th.

Select the Second to Last Element

li:nth-last-child(2) {
    color: green;

Selects the 9th because we have 10 elements here, but if there were 30 elements it would select the 29th.

Wanna play?

Try the tester.

Browser Support

Interestingly enough, :first-child was supported by IE 7, but it’s not until IE 9 where the rest of this stuff is supported. Other than IE there isn’t much browser support concern, and if you are worried about IE, then useSelectivizr. If browser support stuff is interesting or important for you, definitely check out When can I use… which tracks this stuff very well.

소스: Useful :nth-child Recipes | CSS-Tricks

How to Manually Update Bash to Patch Shellshock Bug on Older Fedora-Based Linux Systems –

With the announcement of the Shellshock Bash Bug, Linux admins around the world have been scrambling to patch their Bash shells so that they’re no longer vulnerable to the exploit. If you have a Fedora, RHEL, or CentOS system that hasn’t reached End-Of-Life, then updating to a patched version of Bash is as simple as:

sudo yum update -y bash

But what if you have a system running Fedora 12, Fedora 13, Fedora 14, Fedora 15, Fedora 16, Fedora 17, Fedora 18, or Fedora 19… or even RHEL/CentOS 3 or RHEL/CentOS 4, or an older SUSE Linux box?  I have a Fedora 12 box I keep around for testing, and an updated version of Bash isn’t available in the repos. In that case, you can actually download the Bash source, manually apply all the patches, and compile and install it manually. It’s not as hard as you think! In fact, check out the comments for reports of people successfully patching all the way back to Fedora 4 using this method!

Ubuntu users: There’s actually no reason this approach won’t work with any Linux-based OS, including Ubuntu. You just need to use your system’s package manager (which is apt if you’re using Ubuntu) to install any required packages you’re missing in Step 3. But if you don’t need to install any additional packages, then these instructions will work just fine on Ubuntu, too.

Before You Start

It’s likely you’ve already done this step before coming here, but here’s how to check to see if you’re vulnerable to the Shellshock Bug. Check your vulnerability by running the following tests from your shell:

Exploit 1 (CVE-2014-6271)

Running the following command in a shell.

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you see “vulnerable” you need to update bash. Otherwise, you should be good to go.

Exploit 2 (CVE-2014-7169)

Even after upgrading bash you may still be vulnerable to this exploit. Try running the following code.

cd /tmp; env X='() { (a)=>\' bash -c "echo date"; cat echo

If the above command outputs the current date (it may also show errors), you are still vulnerable. If it just spits out the word “date,” then you’re fine against this exploit. It’s possible after running this test that you’ll have new file named  “echo” in your /tmp directory. If that’s the case, it’s fine to delete it. IMPORTANT: Some of the tests floating around out there for this exploit (including the one I used to reference) include the command “rm -f echo” and could potentially delete the /bin/echo file on your system… which (ironically) is required when building a patched version of Bash. Don’t attempt any tests that include “rm -f echo.” If you didaccidentally remove your /bin/echo file, you can restore it by searching for an archive of the core-utils RPM package for your particular system, then use “rpm -iv –replacepkgs” when installing it to force it to re-install and restore the deleted /bin/echo file.

Exploit 3 (???)

Here is another variation of the exploit.

env -i X=' () { }; echo hello' bash -c 'date'

If the above command outputs “hello”, you are vulnerable.

Exploit 4 (CVE-2014-7186)

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"

If you see “CVE-2014-7186 vulnerable, redir_stack” as part of the output, you are vulnerable to this exploit.

Exploit 5 (CVE-2014-7187)

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

If you see “CVE-2014-7187 vulnerable, word_lineno” as part of the output, you are vulnerable to this exploit. IMPORTANT: Keep in mind that as new Bash exploits are being discovered, new patches are being released by the Bash developers. For example, this article was first published on Sep 26, 2014, and additional patches were released within 2 days (which are now included in the instructions below). Still another patch was released on October 1, 2014. I will continue to update this post as new patches are available. Keep in mind that if the current patches don’t fix all the above known vulnerabilities on your system, you are still better off patching to the highest level possible, and then re-patching later (by simply following these instructions again) when new patches are released.

Step 1: Back up your existing Bash binary

Find out where your existing bash binary is located on your system with:

which bash

You’ll get a response like:


Backup that file with:

sudo cp /bin/bash /bin/bash.old

Step 2: Determine which version of Bash you’re running

Now you’ll need to determining which version of bash your system is running. If you’re running Fedora 12, for example, it’s probably version 4.0. You can find out your version with:

bash --version

which will spit out a version number that looks something like this:

GNU bash, version 4.0.1(1)-release (i686-redhat-linux-gnu)

The first two numbers in 4.0.1 means you’re running Bash version 4.0. Remember your version number, as you’ll need that later. The third number in 4.0.1 can be a bit confusing, because it will mean something different based on where it came from. In this example, because “redhat” appears in the description, the third number is the build number in the RedHat repositories. However, if your output looked like this:

GNU bash, version 4.0.45(1)-release (i686-pc-linux-gnu)

the fact that it says only “pc” in that part of the description means Bash was manually compiled on your system (probably by you) and so in that case, the third number refers to the patch level of Bash version 4.0. Your goal at the end of this post is to have Bash report a version that looks like this, with the highest possible patch level. Do not confuse the Bash version with the patch level! Your goal during this fix should be to keep your version number the same, but increase your patch level to the highest possible number. A higher version number doesn’t necessarily mean you’re protected. Being patched to the highest patch level, regardless of your version number, is what you care about in this case. Finally, as you move through the following steps, resist the urge to move to a newer version number of Bash versions… as you’ll probably end up causing more problems than you’ll fix. Patching your current version of Bash is the best option to ensure things keep working on your system.

Step 3: Set up your fix environment

Whenever I’m working with source code on a Linux box, I like to keep everything in the /usr/local/src directory. So create a new subdirectory for fixing bash, and then jump into that directory, with:

mkdir /usr/local/src/bashfix
cd /usr/local/src/bashfix

You should also make sure you have a few required packages that will come in handy later (like patch, byacc, bison, autoconf, etc.) do:

sudo yum install patch byacc textinfo bison autoconf gettext ncurses-devel

Step 4: Download the Bash source

Locate the matching source code for the version of Bash you’re already running on the FTP server. Since my test system was using 4.0, that’s what I’ll download in this example, but you should obviously download the one that’s appropriate for your system. Again, resist the urge to upgrade to a newer version (such as 4.1, 4.2, or 4.3 in this example). This can potentially create serious problems. Just stick with what you’ve already got for now. Download and extract the appropriate Bash source code into your fix directory with:

tar zxvf bash-4.0.tar.gz

You should now have a new sub-directory containing the bash source. In this example, that directory is /usr/local/src/bashfix/bash-4.0. Move yourself into the newly extracted bash source code directory with:

cd bash-4.0

Step 5: Download and Apply the Patches

If you check the FTP server where you downloaded the source code, you’ll also see a few sub-directories for each major version that contain all the patches for that version. Different versions of Bash have a different number of patches. In our example, the patches are located in Checking that directory (as of  Oct 5, 2014) shows a total of 44 patches for version 4.0, from  bash40-001 to bash40-044. Your first option is to download the first patch, apply it to the source code, then download the second patch, apply it to the source code, and so on. Don’t do this just yet, because I’m going to show you a faster way to do it. But you should at least understand what’s happening before you automate it. The command you’d use to download the first patch and apply it in a single step would be (again, don’t do this… it’s just for illustration):

curl | patch -p0

That command uses curl to download the patch 001, then pipes the downloaded patch into the patch command, which patches the source code in that directory (you can check the patch man page for more details, if you want). If you did this manually, you’d have to repeat this command for each individual patch file, changing the 001 to 002, and then again changing it to 003, and so on until you reached the final patch. But my buddy Steve Cook helped me write a script (I stored it on GitHub as a Gist) that will automate all the patching for you. You just need to tell it the bash version you’re patching, and the total number of patches available for that version. Check it out:

# A quick script file for downloading an applying multiple patches when manually compiling GNU bash on Linux
# Written (mostly) by Steve Cook with (a little) help from Steve Jenkins
# This really seems like a lame way to have to do this, but it works. 🙂 Use at your own risk.
# You can edit these variables
# You probably don’t want to edit anything below this line
for i in `seq 1 $lastpatch`;
number=$(printf %02d $i)
echo $file
curl -k $file | patch -N -p0

Make sure you’re in the Bash source code directory you extracted, then download the “raw” version of the script we wrote with:


Edit the file with your favorite text editor and set the version, nodotversion, and lastpatch variables in the script to the appropriate values for your situation (the nodotversion is simply the version number of bash without a dot in the middle). In our example, the variables are 4.0 (because we’re using Bash 4.0), 40 (same as the version without the dot), and 44 (since there are 44 total patches available for this version of Bash). Depending on your version, the number of patches will be different.

I do my best to stay on top of this issue, but It’s possible that even more patches are available in the patches directory before I’ve had a chance to update this article. You should always set the lastpatch variable in the script to the last patch you see in the directory to ensure the highest level of vulnerability protection. Save your edited file, then make it executable with:

chmod 755

Now run it inside the Bash source code directory with:


Depending on your connection speed, it shouldn’t take very long to download all the patches and apply them. You’ll see each download and patch happen on your screen as the script runs. Keep an eye out for any error messages. The very last one should look something like this:
 % Total % Received % Xferd Average Speed Time Time Time Current
 Dload Upload Total Spent Left Speed
102 3882 102 3882 0 0 10438 0 --:--:-- --:--:-- --:--:-- 53178
patching file builtins/evalstring.c
patching file parse.y
patching file shell.h
patching file patchlevel.h

You can verify your source is patched to the level you want with:

cat patchlevel.h

If you look near the end of that file and see #define PATCHLEVEL followed by the last patch available for your version, then your source is patched to the highest level and should address the Shellshock Bug. Now you’re ready to build the patched version of your bash binary.

Step 6: Build and Install your Patched Bash Binary

It’s best if the “configure” and “make” steps in this section are performed as a regular, non-root user. However, on particularly older systems, if you’re getting errors other than missing dependencies when running “configure,” you may just have to do them as root.

In the source code directory, do:


You’ll see your system check to make sure everything is ready for your build. If you don’t see any errors, go ahead and make the new binary with:


Then test with:

make test

When everything is done you should be able to do this command:

ls -la bash

And you’ll see a newly build Bash binary with a timestamp of just a few seconds ago, like this:

-rwxrwxr-x 1 root root 2273014 2014-09-28 08:37 bash

Now copy the new binary to where your old bash binary was located in Step 1 (which is almost certainly /bin/bash) with:

sudo cp -f bash /bin/bash

Step 7: Test Your Fix

Now that you’ve manually downloaded, patched, compiled, and installed a new bash, you should test it to make sure you’re no longer vulnerable. Make sure your current shell session is using your newly compiled bash by simply running the new location from the command line. In this example, that would be:


First, check to make sure you’re running the newly compiled version with:

bash --version

The output should look like:

GNU bash, version 4.0.44(1)-release (i686-pc-linux-gnu)

The 4.0.44 means you’re running Bash 4.0 at patch level 44. If that was the highest patch you applied to your source, then you are running the version you just built. Now run the vulnerability tests at the top of the article again. As I stated earlier, it’s possible that patches aren’t available to address all of them yet, but you should still patch to the highest level available, and then check back frequently to see if newer patches are available. Also, make sure you log out of any current shell sessions, and log in again using your new shell.

UPDATE! Step 8: Check For (and Kill) Any Old Bash Binaries in Memory

My buddy and fellow Linux sysadmin Todd Lyons emailed me a few days after I wrote this post, and informed me that (particularly on Fedora-based systems) he’d discovered that the old vulnerable Bash binary might still be in memory — even after building and installing a patched version. When I tested his theory on my system, I found he was absolutely right.  So once you’re finished with this patch, read my post on how to prevent your vulnerable Bash binary from being “resurrected.”

If this article was helpful to you, I’d appreciate you sharing or tweeting it! :)

Congratulations on a successful fix! As always, I welcome your questions, comments, and feedback below!

UPDATE #2: Fully Automated Bash Update Script

A generous reader of my blog named Mike Marino was kind enough to write a script based on the steps in this article to cleverly automate the manual Bash update process (including the patching functions of the script). I’ve created a Gist of the script he emailed to me, and named it It essentially follows all the steps in this post, including figuring out your current version of Bash and which patches you need. Mike reports that he’s “been using it to resolve Shellshock on hundreds of hosts which  are stuck running officially unsupported versions of OSes.” It works great! I still recommend that you understand all the steps it’s doing before you pull the trigger, but if you’ve read this far, I’m assuming you already do.

When I replied to Mike to thank him, and ask if I could link to his blog or Twitter feed, his response was “I do not have a blog or anything. Thanks for the offer though. Just my way of giving back on all that you gave us. You can just mention a reader submitted it based off all your awesomeness.”

So thanks, Mike! Your script is awesomeness. :)

# A shell script that fully automates the “manual” patching of GNU Bash, using source and all known official patches.
# Contributed by Mike Marino, based on Steve Jenkins’ manual Bash patching and compiling procedure at:
# This script is a “continuation” of Steve Cook’s at:
# Version 1.0 – October 10, 2014
# Variables
# Lets make sure we have sudo
sudo -v
# Auto-detect bash version
echo -n Detecting Bash Version:
fullversion=`bash –version | head -n1 | sed s/^.* \([0-9]\{1,\}\.[0-9]\{1,\}\.[0-9]*\).*$/\1/g`
version=`echo ${fullversion} | awk -F. {print $1″.”$2} | sed s/^\([0-9]\{1\}\.[0-9]\{1\}\).*$/\1/g`
curpatch=`echo ${fullversion} | awk -F. {print $3}`
no_dot_version=`echo ${version} | sed s/\.//g`
echo ${fullversion}
# Auto-detect last patch number
echo -n Grabbing Latest Patch for bash-${version}:
lastpatch=`curl –silent –insecure${version}-patches/ | grep bash${no_dot_version}-[0-9]*.sig | tail -n1 | sed s/^.*\”bash${no_dot_version}-\([0-9]*\).sig\”.*/\1/g`
echo ${lastpatch}
# If the patch versions are the same do not update
if [[ `echo ${lastpatch} | sed s/^[0]*//g` -eq ${curpatch} ]]; then
echo -e No Bash Update:\n\tCurrent Version: ${fullversion}\n\tLatest Patch: ${lastpatch}
exit 1
# Setup: backup bash
echo -en Setup: Backing up bash\r
sudo cp /bin/bash /bin/bash.old
# Setup: create directories
echo -en Setup: Creating directories\r
sudo mkdir -p ${dirBashfix}
cd ${dirBashfix}
# Setup: install required packages
echo -en Setup: YUM Installing packages…\r
sudo yum -q -y install patch byacc textinfo bison autoconf gettext ncurses-devel gcc test make
# Setup: download bash version, extract, then hop in
echo Setup: Downloading bash-${version} source and extracting
sudo wget –no-check-certificate${version}.tar.gz &&
sudo tar zxvf bash-${version}.tar.gz
cd bash-${version}
# Now cycle through and build it
echo Processing: Patching patch source
for i in `seq 1 $lastpatch`; do
number=$(printf %03d $i)
echo ${file}
curl ${file} –insecure | sudo patch -N -p0
# Lets build it
echo Processing: Building bash from patched source then testing
sudo ./configure &&
sudo make &&
sudo make test &&
# Copy to /bin/bash and display info
echo Copying: Bash to /bin/bash
sudo cp -f bash /bin/bash
ls -lh /bin/bash
echo Complete!
exit 0

Further Reading:

Thank you to the authors of these blog posts, which were helpful in patching Bash on my “outdated” Fedora 12 test box, as well as in writing this post.

BASH vulnerable 확인 방법

각 에러 번호별로 vulnerable 확인 명령어 집합.


Exploit 1 (CVE-2014-6271)

There are a few different ways to test if your system is vulnerable to shellshock. Try running the following command in a shell.

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you see “vulnerable” you need to update bash. Otherwise, you should be good to go.


Exploit 2 (CVE-2014-7169)

Even after upgrading bash you may still be vulnerable to this exploit. Try running the following code.

env X='() { (>\' bash -c "echo date"; cat echo; rm ./echo

If the above command outputs the current date (it may also show errors), you are still vulnerable.

Exploit 3 (???)

Here is another variation of the exploit. Please leave a comment below if you know the CVE of this exploit.

env X=' () { }; echo hello' bash -c 'date'

If the above command outputs “hello”, you are vulnerable.

Exploit 4 (CVE-2014-7186)

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' ||
echo "CVE-2014-7186 vulnerable, redir_stack"

A vulnerable system will echo the text “CVE-2014-7186 vulnerable, redir_stack”.

Exploit 5 (CVE-2014-7187)

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash ||
echo "CVE-2014-7187 vulnerable, word_lineno"

A vulnerable system will echo the text “CVE-2014-7187 vulnerable, word_lineno”.

Exploit 6 (CVE-2014-6278)

shellshocker='() { echo You are vulnerable; }' bash -c shellshocker

You shouldn’t see “You are vulnerable”, if you’re patched you will see “bash: shellshocker: command not found”

Exploit 7 (CVE-2014-6277)

bash -c "f() { x() { _;}; x() { _;} <<a; }" 2>/dev/null || echo vulnerable

If the command outputs “vulnerable”, you are vulnerable.

postgresql 간단설정

1. Password 설정
– ALTER USER postgres with password ‘password’;

2. database 생성
-> 생성 후 oracle등의 dual 테이블을 사용하고 싶으면 명령 수행
\c workpress
create table dual ( dummy varchar(1));
insert into dual values ( ‘x’);

3. 외부접속 설정
1) data폴더안의 pg_hba.conf 파일에 아래라인 추가 (소스 컴파일 시 /install/dir/data/pg_hba.conf 파일)
host all all md5

2) data폴더안의 postgresql.conf 파일에 설정된 listen address 수정 (소스 컴파일시 /install/dir/data/postresql.conf)
listen_addresses = ‘*’

남아있는 설정 : 사용자 생성, 사용자 권한 설정, 사용자 소유DB설정 등..

centos yum offline/CD 설치.

– 설치 DVD 또는 패키지 파일 ( 여기에서는 CentOS 6.5 버전의 DVD1 , DVD2 번을 사용했음)


  • dvd1번과 2번을 적당한곳에 복사한다(/home/me/dvd1 , /home/me/dvd2) => 복사하지 않고 CD가 마운트 된 위치만 알고있어도 상관없음.
  • vi /etc/yum.repos.d/CentOS-Media.repo
  • baseurl 다음라운 2줄 추가 : file:///home/me/dvd1 , file:///home/me/dvd2

– yum –disablerepo=\* –enablerepo=c6-media install gcc <== 굵은 부분만 추가하여서 실행하면 됨.