Vnc server
1)Package
for redhat: tigervnc-server (server package)
tigervnc
(client package)
2)Switch
to the user that we want to be remote login
su root //or creat new user and switng to that
check hostname or edit to whatever want
hostname newhostneme
or
vi /etc/network
now add self ip i.e. server ip to /etc/hosts
192.168.0.30 nameOfHost //then only we will be able to
127.0.0.0 localhost.localdomain //connect from client using IP
Save quit
3)Now issue the command:
Vncpasswd
Type in passward
4)Configure
/etc/sysconfig/vncservers
Add at the end of line
VNCSERVERS="1:vncuser"
VNCSERVERARGS[1]="-geometry 1600x1200” //delete text after 1200 to clerify
// do google
NOTE: You can set the geometry to whatever resolution you require.
In the above section, you can set up multiple users for connection. Say you
had three users that needed access using different resolutions. To accomplish
this, you could enter something like:
VNCSERVERS="1:vncuser1 2:vncuser2
3:vncuser3"
VNCSERVERARGS[1]="-geometry 640x480"
VNCSERVERARGS[2]="-geometry 800x600"
VNCSERVERARGS[3]="-geometry 1600x1200"
5)Enable
vnc service
service vncserver start
[to get the assigned port nuber do ( netstat –ntlp
| grep vnc ) it will report 5901 for “1:vncuser11”
; 5902 for “2:vncuser2”
respectively to all assigned users...]
service vncserver stop
If the VNC server started and
stopped cleanly, set VNC up to start at boot with the command:
chkconfig vncserver on
6) Create
xstartup scripts
You now need to go into each user
that will be logging in with VNC and editing their ~/.vnc/xstartup
script. Within that script, you should find the following:
#!/bin/sh
# Uncomment the following two lines for normal
desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc
[ -x /etc/vnc/xstartup ] && exec
/etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb
$HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title
"$VNCDESKTOP Desktop" &
twm &
Uncomment the following two lines
(remove the "#" characters):
- unset SESSION_MANAGER
- exec /etc/X11/xinit/xinitrc
Save that file and you're ready
to move on.
7)Edit
iptables
In order for the VNC connections
to get through, you must allow them with iptables. To do this, open up the file
/etc/sysconfig/iptables and add the line:
-A INPUT -m state --state NEW -m tcp -p tcp -m
multiport --dports 5901:5903,6001:6003 -j ACCEPT
Or
iptables -I INPUT -m state --state NEW -p tcp --destination-port 5901 -j ACCEPT
Save the file and restart
iptables with the command:
service iptables restart
8)Start
the VNC server
Issue the command:
service vncserver start
9) Try
from client os
Vncviewer
192.168.0.30:1
The last degit is restpective to the number ginen in [VNCSERVERS="1:vncuser"]
Install Samba Server on Red Hat Enterprise Linux/CentOS/Scientific
Linux 6
Recently the latest version of
Scientific Linux 6 was released. Scientific Linux is a
distribution which uses Red Hat Enterprise Linux as its upstream and aims to be
compatible with binaries compiled for Red Hat Enterprise. I am really impressed
with the quality of this distro and the timeliness with which updates and
security fixes are distributed. Thanks to all the developers and testers on the
Scientific Linux team!
In this post I will discuss installing Red Hat Enterprise
Linux/CentOS/Scientific Linux 6 as a Samba server. The instructions should also
be relevant to other Linux distros including CentOS. This example will rely on
a local user database as the mechanism to provide security. In future posts I
may discuss more complex scenarios including integrating the Samba server into
Windows domains and Active Directory.
Let’s start off by installing the Samba server package and its dependencies:
# yum -y install samba
It is a good idea to set up a distinct group to allow access to the
directory we will share. I will specify a group ID to prevent any overlap with
the default groups created when individual users are added, which on most Linux
distros these days start at 500 or 1000.
# groupadd -g 10000 fileshare
Now we will create a directory that will host our Samba share:
# mkdir /home/data
We need to modify the permissions on the directory to allow write access for
users in our new group:
# chgrp fileshare /home/data
# chmod g+w /home/data
SELinux
UPDATE (5/10/2011): Recently I was setting up a Samba share
on an existing file system that already contained files and I was unable to get
SELinux configured to allow Samba to function correctly. This occurred even
with using the -R option specified below to re-curse and relabel the existing
files. So be aware that you may have problems like I did and you may need to
set SELinux to permissive or disabled in the “/etc/selinux/config” file. In my
case there were no denials logged in the “/var/log/audit/audit.log” so it was
very difficult to troubleshoot.
Now we need to modify SELinux to allow access privilege to our new Samba
share. By default this is denied and users will be unable to write files to the
share. Details of the SELinux configuration needed can be found in the default
config file “/etc/samba/smb.conf”.
Here are some good references regarding SELinux:
http://www.crypt.gen.nz/selinux/disable_selinux.html
http://wiki.centos.org/HowTos/SELinux
Now run the SELinux config command to allow user access to the Samba share
directory. New directories and files created under our Samba share directory
will be automatically inherit the SELinux context of the parent
directory. Use the -R option with “chcon” to re-curse if there are
existing files in the directory you are sharing:
# chcon -t samba_share_t /home/data //very
important part
Now we will create a user to access the Samba share. The command options
specify to add the user to a supplementary group “fileshare”, do not create a
home directory, and set the login shell to “/sbin/nologin” to prevent logins to
the console. We only want the user access to the Samba file share:
# useradd -G fileshare -u 1000 -M -s
/sbin/nologin aaron
Or
#
useradd aaron //add new user
# chgrp fileshare
aaron //change the user group to aaron
Assign a password to this user, although the user shouldn’t have any console
login privileges:
# passwd aaron //adding
password to the user is must
Now we need to set up our Samba configuration file. I will move the
existing config file and create a fresh copy to be more concise. But don’t
delete it, as it contains a good amount of documentation so it is a handy
resource if you want to add directives later.
Move the existing file and edit the new file:
# mv /etc/samba/smb.conf
/etc/samba/smb.conf.bak
# vi /etc/samba/smb.conf
Now edit the new “smb.conf” file and add parameters like this:
[global]
workgroup = WORKGROUP
server string = samba
security = user
passdb backend = tdbsam
load printers = no
[data]
comment = data directory
path = /home/data
writeable = yes
public = no
The “global” section contains directives that apply to the whole Samba
instance. We can define the workgroup or domain this server is a member of,
what security mechanism to use (user, share, domain), and the password database
type “tdb”. The old “smbpasswd” password file is no longer recommended for use
on new installations. The “load printers” directive I set to “no” because I
won’t be using the CUPS printing system and connection refused errors will show
up in “/var/log/messages” unless this is specified.
The 2nd section (and on if you have more than one share) has details on each
Samba file share. In this case the share is named “data”, we can define if it
is writeable, and “public” defines whether users not in the Samba password
database can access the share.
We should test the parameters of the “smb.conf” file to make sure there are
no errors:
# testparm
Once you’ve run the “testparm” command and received no errors in the output
you should be set to go. You may notice that some of the parameters won’t show
in the output, this is fine and indicates that some are the Samba default.
We’ll now make the Samba password for the user we are adding:
# smbpasswd -a aaron
New SMB password:
Retype new SMB password:
I received a bunch of output after entering the password that you can see
below. From what I can tell this not a problem and it printed a message at the
bottom that the user was added. Later when I fired up Samba and connected to
the share with this user everything worked normally.
tdbsam_open: Converting version 0.0
database to version 4.0.
tdbsam_convert_backup: updated /var/lib/samba/private/passdb.tdb file.
account_policy_get: tdb_fetch_uint32 failed for type 1 (min password
length), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 2 (password
history), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 3 (user must logon
to change password), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 4 (maximum password
age), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 5 (minimum password
age), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 6 (lockout
duration), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 7 (reset count
minutes), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 8 (bad lockout
attempt), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 9 (disconnect time),
returning 0
account_policy_get: tdb_fetch_uint32 failed for type 10 (refuse machine
password change), returning 0
Added user aaron.
To confirm that the user was added to the Samba tdb database use the
“pdbedit” command:
# pdbedit -w -L
Now we need to make changes to the “iptables” firewall startup config file.
Backup the file and edit:
# cp /etc/sysconfig/iptables
/etc/sysconfig/iptables.bak
# vi /etc/sysconfig/iptables
Add the first line accepting packets on TCP/445. Be sure and add it above
the last line of the “input” chain with the “Reject” target, that way the rule
will be processed.
-A INPUT -p tcp --dport 445 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
Now you can edit the “smb” daemon to start automatically, then start “smb”:
# chkconfig smb on
# service smb start
Client part
If you now switch over to a Samba/SMB client you should now be able to map a
drive or browse the shares on the Samba server. If you want to browse the
shares available you will need to manually enter something like “\\server1″ or
“\\192.168.100.1″ without quotes in the address bar of Windows Explorer, the
server won’t appear in Network Places. To enable full network browsing more
configuration would be needed and you would probably need to enable the “nmb”
daemon.
From windows open file explorer and type in
\\ip address\sharefolder\
and
hit enter
From linux host open terminal and type-in
Smbclient –U server-samba-username //ip address/sharefolder/
Press enter.
It will prompt for password and enter password given before while “smbpasswd”
Or use web browser
at
//ip-address/sharefolder/
Reference
http://www.howtoforge.com/fedora-13-samba-standalone-server-with-tdbsam-backend
Setting Up a Linux Gateway
Setting up a Linux gateway can be a rewarding experience in
both home and commercial environments.
Networks are extremely common these days—you
see them in businesses, schools, even homes. Networking is popular because it
allows users to share resources. You can share files, printers and a myriad of
other devices in a network. Now, wouldn't it be great if you could share an
Internet connection? With Linux, you can.
Setting up Linux as an Internet gateway is not difficult to do. A Linux
gateway allows two or more computers to use the Internet at the same time.
While doing so, only the gateway's IP address will be visible on the Internet.
The rest of the computers will be “hidden” behind the gateway. This is called
IP masquerading.
What can you do with this setup? Well, if you have four computers connected
to the gateway, you can surf the Web from any of the four computers at the same
time. You can run telnet sessions, go on IRC (Internet relay chat), read
newsgroups, etc.—
almost anything you can do on the Internet can be
done. Of course, there are certain things that may need your attention, and I
will discuss them as well as setting up both Linux and Windows machines to use
the gateway.
First of all, you need a working TCP/IP network. I assume your network is up
and running, and all your machines are able to “see” each other.
I will discuss setting up IP masquerading using Linux kernel 2.2.
x
and ipchains 1.3.
x. If for some reason you are running an early kernel
such as 1.
x.
x, please refer to Chris Kostick's articles on IP
masquerading in issues 27 and 43 of
Linux Journal.
Also, please make sure you have a copy of the
Linux IP Masquerade mini
HOWTO (
http://ipmasq.cjb.net/) by
Ambrose Au and David Ranch. It contains much more detailed information on
setting up IP masquerading, including setting up Macintosh and Windows NT
clients. It also contains a useful FAQ should you run into problems. This
article is based on that mini HOWTO as well as personal experience.
I also assume you are familiar with basic Linux system administration, and
that you know how to recompile your kernel and modify your
init
scripts.
The next thing to figure out is what you want to do. How many machines are
on the network? Which machine do you wish to set up as the gateway? Which
machines will be the clients? What operating system is each machine running?
The answers to these questions can be complex and unique, so for the purposes
of this article, we will use the setup shown in Figure 1. This is a three-node
network with a Linux gateway (antioch), a Linux client (nazareth) and a Windows
95 client (lystra).
Figure 1. Gateway Setup
Let's start by setting up the gateway, which in our case is antioch
(192.168.0.1). Antioch runs Linux 2.2.
x, and in order for it to become
a gateway, we need to turn on certain kernel options. My gateway has the kernel
options shown in Table 1 turned on.
Table
1
After booting our newly compiled kernel, we will have to load a few kernel
modules using either
insmod or
modprobe:
/sbin/insmod ip_masq_user
/sbin/insmod ip_masq_raudio
/sbin/insmod ip_masq_ftp
/sbin/insmod ip_masq_irc
It would be wise to add these lines into one of your init scripts so they
will run on every startup. There are other kernel modules related to IP
masquerading; for a full list, type the command
/sbin/modprobe -l | grep ip_masq
Linux 2.2 does not turn on IP forwarding by default. To find
out whether IP forwarding is switched on, check the contents of the file
/proc/sys/net/ipv4/ip_forward. If it is 0, IP forwarding is off; if 1,
it is on.
# cat /proc/sys/net/ipv4/ip_forward
0
# echo "1" > /proc/sys/net/ipv4/ip_forward
# cat /proc/sys/net/ipv4/ip_forward
1
Again, it is wise to add the line which turns on IP
forwarding (the one with the echo command) to
one of your init scripts.
Now we come to an interesting situation. How do we know who gets to use the
gateway and who doesn't? This is where
ipchains
comes in. My current policy is to deny access to the gateway from everybody
unless explicitly allowed. For example, let's say we want only our client
machines nazareth and lystra to access our gateway and no one else. In order to
do this, we have to issue the following commands:
ipchains -P forward DENY
ipchains -A forward -s 192.168.0.2/255.255.255.0\
-j MASQ
ipchains -A forward -s 192.168.0.3/255.255.255.0\
-j MASQ
If, on the other hand, we want everybody on the network 192.168.0.* to use
the gateway, we can issue these commands:
ipchains -P forward DENY
ipchains -A forward -s 192.168.0.0/255.255.255.0\
-j MASQ
Note that we assume the netmask is 255.255.255.0. If your
netmask is different, simply change the values accordingly. There are many
other things you can do with ipchains; however, they are beyond the scope of
this article. I trust that the two simple examples above will get you started.
(See also “Building a Firewall with IP Chains” by Pedro Bueno,
http://www.linuxjournal.com/lj-issue/issue68/3622.html.)
That's it! The gateway is now up and
running. Remember to add the relevant lines to the startup scripts. Also
remember to connect to the Internet before testing your gateway. Now let's set
up the clients.
RAID
Creating a RAID Device With mdadm
To create a RAID device, edit the /etc/mdadm.conf
file to define appropriate DEVICE
and ARRAY
values:
DEVICE /dev/sd[abcd]1
ARRAY /dev/md0 devices=/dev/sda1,/dev/sdb1,/dev/sdc1,/dev/sdd1
In this example, the DEVICE
line is using traditional file name globbing (refer to the glob
(7) man page for more information) to define the
following SCSI devices:
/dev/sda1
/dev/sdb1
/dev/sdc1
/dev/sdd1
The ARRAY
line
defines a RAID device (/dev/md0
) that is
comprised of the SCSI devices defined by the DEVICE
line.
Prior to the creation or usage of any RAID devices, the /proc/mdstat
file shows no active RAID devices:
Personalities :
read_ahead not set
Event: 0
unused devices: none
Next, use the above configuration and the mdadm
command to create a RAID 0 array:
mdadm -C /dev/md0 --level=raid0 --raid-devices=4 /dev/sda1 /dev/sdb1 /dev/sdc1 \
/dev/sdd1
Continue creating array? yes
mdadm: array /dev/md0 started.
Once created, the RAID device can be queried at any time to
provide status information. The following example shows the output from the
command mdadm --detail /dev/md0
:
/dev/md0:
Version : 00.90.00
Creation Time : Mon Mar 1 13:49:10 2004
Raid Level : raid0
Array Size : 15621632 (14.90 GiB 15.100 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Mon Mar 1 13:49:10 2004
State : dirty, no-errors
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Chunk Size : 64K
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
2 8 33 2 active sync /dev/sdc1
3 8 49 3 active sync /dev/sdd1
UUID : 25c0f2a1:e882dfc0:c0fe135e:6940d932
Events : 0.1
Replacing a Faulty Device
To replace a particular device in a software RAID, first
make sure it is marked as faulty by running the following command as root
:
mdadm
raid_device
--fail
component_device
Then remove the faulty device from the array by using the
command in the following form:
mdadm
raid_device
--remove
component_device
Once the device is operational again, you can re-add it to
the array:
mdadm
raid_device
--add
component_device
Example 6.3. Replacing a faulty device
~]# mdadm --detail /dev/md3 | tail -n 3
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
Imagine the first disk drive fails and needs to be replaced.
To do so, first mark the /dev/sdb1
device as
faulty:
~]# mdadm /dev/md3 --fail /dev/sdb1
mdadm: set /dev/sdb1 faulty in /dev/md3
Then remove it from the RAID device:
~]# mdadm /dev/md3 --remove /dev/sdb1
mdadm: hot removed /dev/sdb1
As soon as the hardware is replaced, you can add the device
back to the array by using the following command:
~]# mdadm /dev/md3 --add /dev/sdb1
mdadm: added /dev/sdb1
Procedure to delete raid device(md0)
Be sure that your RAID is NOT RUNNING before changing the partition types.
Use
raidstop /dev/md0
//to stop the device.
If you set up 1, 2 and 3 from above, autodetection should be set up. Try
rebooting. When the system comes up, cat'ing
/proc/mdstat
should tell you that your RAID is running.
Then
mdadm –-remove /dev/mdX //the format is seems wrong, just tweek before
using it.