//---------------------------------------------------------// //---------- austin linux june meetup ----------// //---------- 06-06-2011 ----------// Much of this information came from RHEL class taught by Scott Purcell, Copyright © 2011, Scott Purcell, CC https://github.com/texastwister/OpenRHCE/ //-------------------------------------------------------// RHEL 6 Virtualization Virtualization Terms Physical Machine: The actual physical machine with RAM, disk space, etc. Virtual Machine: A logical construct provided by hardware and/or software capabilities that can run an independent OS and perform work as though it were a physical machine. Hypervisor: A specialized OS that provides virtual machines. Xen: A hypervisor previously available on Red Hat operating systems that was implemented as a modified version of the Linux kernel. KVM: Kernel Virtual Machine, the hypervisor Red Hat currently supports on RHEL6. It is implemented within (as a set of kernel modules) the mainstream Linux kernel. Guest: The operating system that runs on a virtual machine. Host: The operating system that runs on a physical machine hosting virtual machines (i.e. the hypervisor). //--------------------// RHEL6 KVM requirements • 64-bit Intel or AMD processor - To confirm, search /proc/cpuinfo for the string lm on the flags line. • CPU Hardware assisted virtualization extensions (enabled in BIOS) - To confirm, search /proc/cpuinfo for the string vmx (for Intel) or svm (for AMD) • 64-bit version of RHEL6 - To confirm, look for x86_64 in the output of `uname -m`. //--------------------// KVM Virtualization Components • KVM kernel modules • libvirt • virsh virtualization shell • virt-manager //--------------------// Installing Virtualization Capabilities At OS Installation: Select the Virtual Host server role --or-- customize packages and select the Virtualization package group. In a kickstart file, these packages can be installed as a group with the @kvm group name. After Installation, with entitlement to t he Virtualization packages, or access to them through a 3rd party repository: `yum install kvm` Other recommended packages: • python-virtinst • libvirt • libvirt-python • virt-manager • libvirt-client • `yum -y install qemu-kvm virt-manager libvirt libvirt-python python-virtinst libvirt-client libguestfs-tools` (permits editing files within a powered-off vm) Virsh Commands Power on a virtual machine: `virsh start ` Gracefully shut down a virtual machine: `virsh shutdown ` Power off a virtual machine: `virsh destroy ` Connect to a virtual machine console (requires guest configuration): `virsh console ` Disconnect from a console of a virtual machine: `^]` ( "ctrl + ]" ) Set a VM to start at boot: `virsh autostart ` `virt-manager` `virt-viewer` `virsh list [--all]` Editing internal vm machine files from host: `export vm1=s4vm1` && `virt-edit $vm1 /etc/inittab [or wh atever]` Creating Virtual Machines with `virt-install` (a command-line tool used to create virtual machines). See the syntax with `man virt-install` or `virt-install --help`. Sample command: # `virt-install --name StXVM3 --ram 768 --disk path=/var/lib/libvirt/images/StXVM3disk1.img,size=8 --network network=default --cdrom /dev/cdrom` SELinux considerations • SELinux expects file-based guest images to be stored in /var/lib/libvirt/images/. Use of other locations with SELinux enforcing will require adding the location to the SELinux policies. 1. Find the context applied to the expected location: # `ls -l -Z /var/lib/libvirt/` drwx--x--x. root root system_u:object_r:virt_image_t:s0 images 2. Add a new context policy: # `semanage fcontext -a -t virt_image_t "/virtstorage(/.*)?"` 3. Set the context to match the newly created policy: # `restorecon -R -v /virtstorage/` `restorecon reset /virtstorage context unconfined_u:object_r:` default_t:s0->system_u:object_r:virt_image_t:s0 //---------- ----------// //---------- creating a virtual bridge ----------// NetworkManager does not support network bridging create a virtual bridge http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization/sect-Virtualization-Network_Configuration-Bridged_networking_with_libvirt.html Change to the /etc/sysconfig/network-scripts directory: Copy ifcfg-eth0 (or src/redhat/rhel-server-6.0-x86_64-dvd.iso /mnt/iso iso9660 rw,loop=/dev/loop0 0 0 whatever) to ifcfg-br0. Modify the network interface to use the bridge DEVICE=eth0 # change the hardware address to match the hardware address your NIC usessrc/redhat/rhel-server-6.0-x86_64-dvd.iso /mnt/iso iso9660 rw,loop=/dev/loop0 0 0 HWADDR=00:16:76:D6:C9:45 ONBOOT=yes BRIDGE=br0 Alter the the bridge script DEVICE=br0 TYPE=Bridge (note the B, not b) BOOTPROTO=dhcp (or set the static info) ONBOOT=yes DELAY=0 Restart the network Configure iptables to allow all traffic to be forwarded across the bridge. # iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT # service iptables save # service iptables restart Restart the libvirt service Verify the bridge //-------------------------------------------------------// RPM information in depth, and create a .rpm file for deployment The Red Hat Network (RHN) The primary delivery mechanism for installable software, updates, errata and bug fixes and systems management functions for an installation of RHEL 6 is the Red Hat Network or RHN. The "cost" of RHEL 6 is really a subscription to this support network. These commands are using in managing an RHN subscription: `man -k rhn` `rhn-profile-sync` - Update system information on Red Hat Network `rhn_check` - Check for and execute queued actions on RHN `rhn_register` - Connect to Red Hat Network `rhnplugin` - Red Hat Network support for yum(8) rhnplugin.conf [rhnplugin] - Configuration file for the rhnplugin(8) yum(8) plugin `rhnreg_ks` - A program for non interactively registering systems to Red Hat Network `rhnsd` - A program for querying the Red Hat Network for updates and information `rhn ` 3rd Party Yum Repositories These are other repositories of installable software, updates, or bugfixes. The yum command can be configured to use them in addition to or instead of the RHN. • Configuration of repositories other than the RHN is accomplished through text configuration files located in the directory: /e for each repository (or group of related repos) should be created in /etc/yum.repos.d/ • The name of each repotc/yum.repos.d/ • A configuration file config file should end in ".repo". • This allows repos to be easily temporarily disabled simply by renaming the file to something like: myrepo.repo.disabled Yum Repository Mandatory Configuration Items Repository ID, a short name for identifying this repository in reports - [some_repo] Name, a longer description of this repository name=My Custom Repository Baseurl, a description of protocol and location needed to locate the repo files. baseurl=ftp://192.168.5.200/pub/rhel6 Yum Repository Common Optional Configuration gpgcheck - Defines whether yum should attempt to validate package signatures. "0" = "off", "1" = "on". gpgcheck=1 gpgkey - Defines (via URL) where the keys for signature validation are located (typically file:///etc/pki/rpm-gpg/) gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release enabled - (Optional) Defines whether this repository should be currently active. "0" = "off", "1" = "on". enabled=1 Managing Software: Using yum Common commands: `yum help` - Displays usage information. `yum list` - Lists all available packages and indicates which are installed. `yum search KEYWORD` - Searches for packages with a keyword in the package metadata. `yum info PACKAGENAME` - Displays information about a package taken from the package metadata. `yum install PACKAGENAME` - Installs a package (obtained from the repository) and any required dependencies. `yum localinstall RPMFILENAME` - Installs a local .rpm file, but uses the repository to satisfy dependencies. `yum remove PACKAGENAME` - Uninstalls a package and any other packages dependent upon it. `yum update PACKAGENAME` - Installs a newer version of the package, if available. `yum update` - Updates an installed package for which a newer version is available. Yum-related man pages `man -k yum` qreposync - synchronize yum repositories to a local directory rhnplugin - Red Hat Network support for yum(8) rhnplugin.conf [rhnplugin] - Configuration file for the rhnplugin(8) yum(8) plugin yum - Yellowdog Updater Modified yum [yum-shell] - Yellowdog Updater Modified shell yum-groups-maUsing yumnager - create and edit yum's group metadata yum-utils - tools for manipulating repositories and extended package management yum.conf [yum] - Configuration file for yum(8) RPM Architecture rpm executable RPM packages -- Files to install + SPEC file (metadata) Local RPM database -- retains metadata from all installed packages (kept in /var/lib/rpm) RPM Package Naming • name-version-release.architecture*.rpm • Version is the version of the "upstream" open source code • Release refers to Red Hat internal patches to the source code • Architecture is one of: • i386,i686 -- 32 bit x86 compatible • x86_64 -- Intel/AMD 64 bit • ppc64 -- Power PC 64 bit • ia64 -- Intel Itanium 64 bit • noarch -- Arch-independent code (scripts, docs, images, etc) • src -- Source code Installing and Upgrading Packages `rpm -i[v,h] name-ver-rel.arch.rpm` - Installs a package `rpm -U[v,h] name-ver-rel.arch.rpm` - Upgrades a package if an older version was previously installed. Otherwise, simply installs the new version. `rpm -F[v,h] name-ver-rel.arch.rpm` - Upgrades a package if an older version is installed. Otherwise, does nothing -- does not install new packages if no older version was installed. Upgrading a Kernel • Always use #rpm -i ... • This leaves the previously installed kernel on the system and in the GRUB menu as a fall-back in case the new version has problems. RPM and Modified Config Files Scenario: niftyapp-1.0-1.el5.rpm uses a config file, /etc/nifty.conf. You tweaked /etc/nifty.conf to fit your system. Now niftyapp-2.0-1.el5.rpm is available with new features that require changes in the .conf file and provides a new default config file. What to do? • If the previous version provided a default config file, the changes are detected. Your modified version of the .conf file is saved as /etc/nifty.conf.rpmsave and the new default config is installed. You can compare the files and modify as needed. • If the previous version did NOT provide a default config file, your version of the .conf file is saved as /etc/nifty.conf.rpmorig and the new default config is installed. You can compare the files and modify as needed. Uninstalling `rpm -e name[-ver][-rel]` • Package removal is never verbose, never shows progress ( -v, -h have not effect) • Package removal only needs the name (or when multiple versions of the same package are installed, sometimes the version or release) but not the architecture or the .rpm extension. RPM over a Network `rpm -ivh ftp://{Host}/path/to/packagename-ver-rel.arch.rpm` `rpm -ivh http://{Host}/path/to/packagename-ver-rel.arch.rpm` And wildcard "globbing" is allowed: `rpm -ivh http://{Host}/path/to/packagename*` //--------------------// //---------- extremely useful commands ----------// Common RPM Queries Query Result rpm -qa lists all installed packages. rpm -q pkg Reports the version of the package. rpm -qf /path/file Reports which package provided the file. rpm -qc pkg Lists all configuration files of the package. rpm -qd pkg Lists all documentation of the package. rpm -qi pkg Reports a description of the package. rpm -ql pkg Lists all files contained in the package. rpm -qR pkg Lists all dependencies. rpm -q --scripts Lists the scripts that run when installing/removing. rpm -q{c|d|i|l|R}p /path/to/packagename-ver-rel-arch.rpm Reports the same info as above, but pulls info from the .rpm file instead of the rpm database. //--------------------// RPM Verification The RPM system satisfies two types of security concerns: 1. Is this package authentic? How do I know it came from Red Hat? 2. Has this package retained integrity? How do I know they haven't been modified? Authenticity and integrity of packages can be confirmed prior to installation with GPG signing and MD5 checksums of the RPM packages. Integrity of files can be confirmed after installation with verification of installed files against the recorded metadata in the package. Validate Package Signatures 1. Import the Red Hat GPG public key (It can be found on the installation CD or in the /etc/pki/rpm-gpg/ directory): `rpm --import /media/disk/RPM-GPG-KEY-redhat-release` or: `rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release` 2. Check the signature of the package in question: `rpm --checksig /path/to/package-ver-rel.arch.rpm` Verify Installed Files `rpm -V` (or --verify) will compare existing files on the system to their pristine state in the packages they came from. There are 8 points of comparison as shown in the following table, in the Michael Jang book and in the rpm man page: Change Codes from `rpm --verify` Change Code Meaning 5 MD5 checksum S File size L Symbolic Link T Modification time D Device U User G Group M Mode Identifying Installed Packages View a list of the packages originally installed on the system: `less /root/install.log` View a list of the packages installed through yum: `less /var/log/yum.log` Query the RPM database for the packages installed right now: `rpm -qa` Managing Software: Building RPMs http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ (for building rpms, go down to section #8) spec Inside an RPM package • files • scripts • metadata The package is defined by a "build specification file" or spec file. A good example of a spec file can be obtained from the source rpm for redhat-release. ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/redhat-release-server-6Server-6.0.0.37.el6.src.rpm Tip: Open .spec files in vim for color highlighting Main contents of a .spec file: • Introduction or preamble: Contains metadata about the package • Build instructions on how to compile the source code or otherwise prepare the package payload. • Scriptlets that specperform the installation, uninstallation, or upgrade. • Manifest of files to be installed, along with their permissions. • Changelog recording the changes made to the package with each revision. Preamble directives Name: Name of the package Version: Version identifier Release: Indicates incremental changes within a version. Group: The package group that should include this package. This can come from the list at /usr/share/doc/rpm-*/GROUPS or can be unique to you. Not related to yum package groups. License: Short Licspecense Identifier as described at http://fedoraproject.org/wikispec/Packaging/LicensingGuidelines Summary: Short (<=50 chars) one-line description. Source: The file tspeco be used as the source code. Add'l sources can be specified as Source0, Source1, etc. BuildArch: Arch to use when building. Defaults to the existing system arch. May also be "noarch" for arch-independent packages. Requires: Requirements that this package needs to run. Can be in the form of files or other packages. BuildRequires: Requirements needed to build this package. Required Spec file sections %description %prep %build %install %cleanspec %files %changelog Package Building Tools These packages will provide tools for setting up a build environment and the ability to create your own packages. • rpm-build • rpmdevtools • rpmlint Setting up a Build Environment As a non-privileged user, run: `rpmdev-setuptree`. This should create the following directory structure in your home directory: ~/rphello-1.0-1.el6.x86_64.rpmmbuild |-- BUILD |-- RPMS |-- SOURCES |-- SPECS \-- SRPMS In that structure, your source files (in a tarball) should be placed in ~/rpmbuild/SOURCES/ and your .spec file in ~/rpmbuild/SPECS/. The hello-1.0-1.el6.x86_64.rpm~/rpmbuild/BUILD/ directory will be a temporary working directory for the build process. And, after the rpmbuild process is complete, the finished binary and source RPMs will be placed in ~/rpmbuild/RPMS/ and ~/rpmbuild/SRPMS/, resphello-1.0-1.el6.x86_64.rpmectively. Viewing the Build Environment When diagnosing build problems, it is sometimes useful to see what files are actually being created in the build environment in order to idehello-1.0-1.el6.x86_64.rpmntify deviations of actual behavior from expected behavior. The tree utility is useful for that. Install tree with `yum install tree`. Invoke tree with `tree ~/rpmbuild` to show the contents of the build environment. Building thehello-1.0-1.el6.x86_64.rpm RPM With the source files in place and a properly configured .hello-1.0-1.el6.x86_64.rpmspec file written, the rpmbuild command can be used to build the rpm either at once, or (for troubleshooting) in stages `rpmbuild -bp ` - Builds through the %prep section -- unpacks sources and applies patches. `rpmbuild -bc ` - Builds through compile -- processes the %prep and %build sections. `rpmbuild -bi ` - Builds through %install -- processes %prep, %build, and %install. `rpmhello-1.0-1.el6.x86_64.rpmbuild -bb ` - Builds only the binary rpm file. `rpmbuild -bs ` - Builds only the source rpm file. `rpmbuild -ba ` - Builds both the binary and source rpm files. Use `rpmbuild --help` or `man rpmbuild` for other options. RPM Building Exercise 1. As root, install rpm-build, rpmlint, rpmdevtools: `yum -y install rpmbuild rpmdevtools rpmlint` hello-1.0-1.el6.x86_64.rpm 2. As a non-privilegeRPMs Your RPMs can be digitally signed to protect users from the possibility of forged packages (any RPM package can execute scripts w/ root d user, create a project directory: `mkdir ~/hello-1.0` (Name this according to the convention: hello-1.0-1.el6.x86_64.rpm-.) 3. Create bash script: ~/hello-1.0/hello.sh #!/bin/bash # hello.sh echo 'hello' exit 0 hello-1.0/hello.sh 4. Create a tarball oRPMs Your RPMs can be digitally signed to protect users from the possibility of forged packages (any RPM package can execute scripts w/ root f the project directory: `tar cvzf hello-1.0.tar.gz ~/hello-1.0/` 5. Create an rpm development environment: `rpmdev-setuptree` 6. Move the tarball to the SOURCES directory. 7. Create a .spec file in the SPECS directory: `vim pkgname.spec` hello-1.0-1.el6.x86_64.rpmor: `rpmdev-newspec -o pkgname.spec` 8. Insert a name (MatRPMs Your RPMs can be digitally signed to protect users from the possibility of forged packages (any RPM package can execute scripts w/ root ch the pkgname on the tarball and directory). 9. Insert a version (Match the version). 10. Leave the release alone. 11. Insert a summary (one line). 12. Insert a group (package group). 13. Insert a license. 14. Insert a URL or delete the line. 15. Insert on the SouRPMs Your RPMs can be digitally signed to protect users from the possibility of forged packages (any RPM package can execute scripts w/ root rce0 line, the name of your tarball. 16. Leave the BuildRoot line alone. 17. Unless your package has prerequisites needed before it can be compiled, delete the BuildRequires line. 18. Unless your package has prerequisites needed before it can work, delete the Requires line. 19. On a blank line below %description, insert a brief description of your package. 20. Leave the %prep and %setup lines alone. 21. If your package does not need to be "built" (compiled), delete the %build, %configure, and make lines. 22. Leave the %instalRPMs Your RPMs can be digitally signed to protect users from the possibility of forged packages (any RPM package can execute scripts w/ root l section header alone. 23. Under the %install section, leave the rm line alone. 24. If your package does not need to be built, modify the make install line to something like this: `install -D myfile $RPM_BUILD_ROOT/path/to/install/dest/myfile` 25. Leave the %clean and the rm -rf lines alone. 26. Under %files, use the following syntax to list each of the files your package will place on the target system: %attr(770,owner,group)/path/to/file 27. Use the following syntax to list each of the directories you package will place on the target system: %dir /root/bin 28. The changelog section can be deleted or left alone. Signing Youhello-1.0-1.el6.x86_64.rpmr RPMs Your RPMs can be digitally signed to protect users from the possibility of forged packages (any RPM package can execute scripts w/ root privileges when installed!). To implement this, first generate and identify a gpg key: `gpg --gen-key` gpg (GnuPG) 2RPMs Your RPMs can be digitally signed to protect users from the possibility of forged packages (any RPM package can execute scripts w/ root .0.14; Copyright (C) 2009 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (RPMs Your RPMs can be digitally signed to protect users from the possibility of forged packages (any RPM package can execute scripts w/ root RPMs Your RPMs can be digitally signed to protect users from the possibility of forged packages (any RPM package can execute scripts w/ root sign only) (4) RSA (sign only) Your selection? RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y GnuPG needs to construct a user ID to identify your key. Real name: Bob Carnaghi Email address: meetup@webpointmorpheus.com Comment: You selected this USER-ID: "Bob Carnaghi " Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: key B9AED1DE marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u pub 2048R/B9AED1DE 2011-06-03 Key fingerprint = 9987 B276 A24A 1210 13A7 4D05 9F3F 8934 B9AE D1DE uid Bob Carnaghi sub 2048R/0DA4CCE9 2011-06-032 The key ID can be seen in the output above, or can be found with gpg --fingerprint. Export the key to a file: `gpg --armor --output ~/RPM-GPG-KEY-ScottPurcell --export B9AED1DE` `cat RPM-GPG-KEY-BobCarnaghi -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.14 (GNU/Linux) mQENBE1jVagBCADVDTOvRl3Z5xPZb6AAl2D3bM/H4kEhyJ+yk1pbVPmu8yu0Cbsl . . . R+J9rjvN8rNpQwm40Gx6RpM7qtP/LodzD46dNfbr87lJ4F+4A3U= =f4Gq -----END PGP PUBLIC KEY BLOCK----- Configure rpm-related tools to use your signature: `echo '%_gpg_name Bob Carnaghi' >> ~/.rpmmacros` or: `echo '%_gpg_name B9AED1DE' >> ~/.rpmmacros` Now packages can be created and signed at the same time with rpmbuild using the --sign option. Or existing packages can be retroactively signed with rpm using the --addsign or --resign options. With a signed package in place, the user intending to install it now needs to import the key: `rpm --import /home/scott/RPM-GPG-KEY-BobCarnaghi` And with the key imported, the package can be verified: `rpm -K rpmbuild/RPMS/x86_64/rhel6rhce-0.5-1.el6.x86_64.rpm` rpmbuild/RPMS/x86_64/rhel6rhce-0.5-1.el6.x86_64.rpm: rsa sha1 (md5) pgp md5 OK Create a Repo with your files (Assumes httpd already installed) `yum -y install createrepo` `mkdir -p /var/www/html/repo/Packages` `cp NewPackage.rpm /var/www/html/repo/Packages` `createrepo -v /var/www/html/repo` `cp /home/me/RPM-GPG-KEY-me /var/www/html/repo` RPM Packaging, Other Documentation: Red Hat Enterprise Linux Deployment Guide, section on "Querying RPM" Man Pages: • rpm (8) • rpm2cpio (8) • cpio (1) //-------------------------------------------------------// nic bonding (teaming in windows) http://www.linuxfoundation.org/collaborate/workgroups/networking/bonding http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-networkscripts-interfaces-chan.html http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sec-Using_Channel_Bonding.html ethtool or mii-tool. 1. create a new file as root named nic_bonding.conf in the /etc/modprobe.d/ directory with the following directive (one directive for each bonding interface to be created. alias bond bonding 2. create a new file for the bond interface, /etc/sysconfig/network-scripts/ifcfg-bond DEVICE=bond0 IPADDR= NETMASK= ONBOOT=yes BOOTPROTO=none USERCTL=no BONDING_OPTS="" 3. convert the existing ifcfg-eth configs to slave off the bonding config: DEVICE=eth BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no Important: put all bonding module parameters in ifcfg-bondN files. Parameters for the bonding kernel module must be specified as a space-separated list in the BONDING_OPTS="" directive in the ifcfg-bond interface file. Do not specify options for the bonding device in /etc/modprobe.d/.conf, or in the deprecated /etc/modprobe.conf file. For further instructions and advice on configuring the bonding module and to view the list of bonding parameters, refer to http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sec-Using_Channel_Bonding.html http://www.cyberciti.biz/tips/linux-bond-or-team-multiple-network-interfaces-nic-into-single-interface.html //-------------------------------------------------------// /etc/inittab //-------------------------------------------------------// Samba Samba is a project providing software capable of utilizing the SMB (Server Message Block) and CIFS (Common Internet File System) protocols to interoperate with systems using MS-Windows-style file and printer sharing. Linux systems can use Samba to: • Act as a client to SMB/CIFS servers • Provide file and printer sharing services to clients • Provide domain controller functionality in a limited subset of possible configurations. //--------------------// Accessing SMB/CIFS Shares • Graphically, using Nautilus: Use Places | Connect to Server, choose Windows share as the Service Type and provide the required credentials. • Occasional, FTP-like access from the command line: `smbclient //server/share/ -U username -W [domain or workgroup]` • Through filesystem mounts: `mount -t cifs //server1/tmp /mnt/share -o credentials=/root/credentials` • /etc/fstab entry: `//server/share /mnt/point cifs credentials=/root/credentials 0 0` • Credentials File contents: user= pass= domain= //--------------------// Samba Packages: • samba • samba-client • samba-common • samba-winbind • samba-domainjoin-gui (Optional Repository) //--------------------// SELinux SELinux notes are at the top of the config file (/etc/samba/smb.conf) and the man page samba_selinux (8). SELinux Port Settings for Samba: `semanage port -l` smbd_port_t |grep smb tcp 137-139, 445 SELinux Booleans for Samba: `semanage boolean -l |grep "smb\|samba"` //--------------------// SELinux fcontexts for Samba: `semanage fcontext -l |grep "smb\|samba"` //--------------------// Services `service smb start` `chkconfig smb on` //--------------------// /etc/samba/smb.conf (Global) workgroup - Specifies a shared Windows Workgroup or Domain name. server string - Provides a description of the server. netbios name - Specifies a name for the server for in implementations where NetBIOS is still used. Interfaces - Used to bind the service only to particular network adapters or IP addresses. Hosts Allow - Used for host-based access control. (roughly equivalent to the firewall) //--------------------// config file: workgroup = {domain | workgroup} /etc/samba/smb.conf Security Types (where does samba go to reference authentication/security info) The security line establishes the security model for the server. This would be one of the following: user - Indicates that user credentials are held on the local server. share - Indicates that credentials are not kept globally on an individual basis. All who report membership in the same workgroup are permitted access to the server and user authentication in configured in the share settings. domain - Used when the Samba Server has been added to a [Windows NT Domain]. User access is authenticated through a primary or secondary domain controller. (samba is not the domain controller) server - User access is authenticated through a peer server that is not a domain controller. (another samba or workgroup server) ads - User access is authenticated through an Active Directory controller. Kerberos must be installed and configured to authenticate this machine's membership in the Domain. //--------------------// Samba Users and Passwords When the security model set to user, local Samba users and passwords must be created. Typically, these accounts use the same user names as those configured on the local system. smbpasswd is the command used: # smbpasswd -a winuser //--------------------// /etc/samba/smb.conf (Shares) [public] comment = Public Share path = /var/ftp/public browsable = yes writable = yes Path must have appropriate filesystem permissions. //--------------------// Testing Configuration Syntax of the smb.conf file can be tested before restarting the service: `testparm` //--------------------// Samba Firewalling Considerations Samba, in its latest version, uses TCP port 445. For backwards compatibility, UDP ports 137 and 138 and TCP port 139 may also need to be opened in some instances. For group share, a) create group & membership first; b) set permissions on the group folder (w/sticky bit + sgid: {2770 | 3770}); c) set selinux context on the directory; 1. install "samba" package 2. `chkconfig smb on` & `service start smb` 3. create samba users & passwd 4. enable selinux boolean 5. configure firewall 6. restart service set up directory structure thus: /shared /share-nfs /share-smb HowTo: Enable Home Directory sharing via Samba 1. Install the appropriate packages. 2. Start and enable the service. 3. Configure the workgroup name in smb.conf. 4. Create the required Samba users and passwords. 5. Enable the SELinux boolean permitting home directory access. 6. Configure the firewall. 7. Restart the service. 8. Test from another system. HowTo: Configure a Group Share 1. Create the appropriate group if required. 2. Create a collaborative directory. 3. Set the SELinux contexts on the shared directory. 4. Define the share in smb.conf. Set the following values: valid users = @groupname writeable = yes (Ensure that the directory permissions are 2770.) or, to allow broader read-only permission: writeable = no write list = @groupname (And relax the directory permissions to 2775.) 5. Restart the service. 6. Test from another system.