:: TechBlog :: » Open Source

Setting up a Minimal Samba Server in Fedora Core 12

elran — Fri, 18 Dec 2009 04:58:47 +0000

Goal:
Minimal FC12 Samba install with low RAM usage, high security, and least amount of configuration.

Why?
Quickly turn an older machine into a modern Fedora Core 12 file server compatible with linux and windows clients. Less software installed means less setup, less maintenance, less updates, and less chance of human error somewhere along the way. The theory here is, the system starts out relatively secure and (if kept up-to-date) should remains so over time.

Side Note:
There are definitely many other ways to go about setting up a Samba server, much of which depends on your networking environment and overall requirements / constraints. This article is meant more as a guide – my notes which describe the method i happen to use – so that if i have to, i can do it all again.

Assumptions:
- Comfortable with install and use of Fedora Core Linux OS (command line)
- Basic understanding of networking concepts (setting up a static IP)
- Some experience with editing the smb.conf file

Features:
- No GUI / Desktop Environment
- Low RAM usage: boots up @ ~80MB with smbd and nmbd running
- SELinux and iptables firewall enabled / configured for use with Samba
- Samba Security level = User

System Resources:
CPU: AMD @ 700MHz
RAM: 192MB

Steps Involved:

Download and burn the Fedora-12-i386-DVD.iso file to dvd
Boot from the disc and go through install process (with less that 200MB RAM it defaults to text mode install – you can also force a text mode install at the boot: prompt by typing: linux text)
Once install is completed and system is rebooted, login as root
Check that networking is up
- type:
```
ifconfig
```
(see if you have an IP address)
- type:
```
dhclient eth0
```
(to use dhcp for now)
Bring the system up to date
- type:
```
yum check-update
```
(to check for updates first)
- type:
```
yum update
```
(say “yes” to install the updates)

- type:

yum list installed

(to see a list of all installed packages)

Check to see what package “groups” got installed by default
- type:
```
yum grouplist > grouplist.txt
```
- type:
```
cat grouplist.txt | more
```
Remove any unwanted package groups
- type:
```
yum groupremove "Mail Server"
```
Add the Samba package group
- type:
```
yum groupinstall "Windows File Server"
```
Configure Samba by editing /etc/samba/smb.conf
- Note, for Vista support (in the Global section) add:
```
client NTLMv2 auth = yes
```
- Note, to hide unreadable files like /lost+found/ (in the Global section) add:
```
hide unreadable = yes
```
- type:
```
testparm
```
(confirm output has no errors in it)
Deal with SELinux security policies (see default smb.conf file for details)
- type:
```
setsebool -P samba_domain_controller on
```
- type:
```
setsebool -P samba_enable_home_dirs on
```
- type:
```
chcon -t samba_share_t /path-to-mounted-directories
```
(remember to mount any/all directories first)
- type:
```
ls -ldZ /path-to-mounted-directories
```
(to confirm it worked)
- Note, for existing shares, to make sure this affects all files and folders recursively add:
```
chcon -R -t samba_share_t /path-to-existing-mounted-directories
```
- Note: to completely disable SELinux protection for smbd daemon (not recommended) type:
```
setsebool -P smbd_disable_trans 1
```
- Note: you can temporarily disable SELinux by putting it into permissive mode – type:
```
getenforce
```
to find out whether SELinux is in permissive [0], enforcing [1], or disabled [2] mode.
- Note: to put SELinux into permissive mode (for testing purposes but not recommended) type:
```
setenforce 0
```
Add samba users
- type:
```
useradd john
```
- type:
```
smbpasswd -a john
```
Configure the firewall to accept samba connections
- type:
```
system-config-firewall-tui
```
(add an asterix next to the line: “Samba”)
Configure the network to use static IP/netmask/gateway/DNS info
- type:
```
system-config-network-tui
```
- select: [Edit a Device Params] and remove the asterix from the line: “Use DHCP”. then, and add static info
Configure the network to use a static Hostname and DNS address (note: DNS settings may not be required)
- type:
```
system-config-network-tui
```
- select: [Edit DNS configuration] then, and add static hostname and dns info
Get the network, smb, and nmb to start automatically next time you reboot
- type:
```
chkconfig --level 3 network on
```
- type:
```
chkconfig --level 3 smb on
```
- type:
```
chkconfig --level 3 nmb on
```
- type:
```
chkconfig --list network
```
(or smb, or nmb to confirm it worked. you can also leave out the servicename to see a list of all services)

Reboot.
Use another computer to check that everything went well.

WordPress Plugin – Notify Admin Only of WP Updates

elran — Tue, 04 Aug 2009 15:42:15 +0000

Update: This plugin is tested and known to be working with WP 2.9.1

ok, with the release of WordPress 2.8.3 – if finally got around to upgrading my Notify Admin Only plugin to work with WP 2.8+

Download Plugin: Notify Admin Only v2.0

in case you’re not sure what this plugin actually does, well, it removes this text from the backend that says: “A new version of WordPress is available! Please notify the site administrator” – (see the images below).

great for admins who don’t want their many users to ever see the WordPress Update nag.

anyway the new code is really simple: (thanks Lazzymonk)

< ?php function stop_wpupdate() { if ( current_user_can('manage_options') ) { return; } else { remove_action( 'admin_notices', 'update_nag', 3 ); } } add_action( 'admin_notices', 'stop_wpupdate', 1 ); ?>

the old plugin is here and only works for WP 2.3 – 2.5 series.

WP 2.3 Plugin – Per Post Creative Commons License

elran — Thu, 21 Feb 2008 22:33:31 +0000

This plugin will add the ability to choose different Creative Commons licensing structures for different posts that you publish to your WordPress blog.

As far as i could tell, there are currently 2 other CC plugins for WordPress – wpLicense and cc-configurator – however both of them only let you set your license on a global level. That is, they let you pick one license for all your posts and pages throughout your entire site. I thought it might be useful if each WP user/author could choose between different CC licenses and be able to set them on a post-by-post basis. So, i modified the wpLicense plugin to do just that.

“The main purpose of this plugin is to give WP admins who run sites with multiple users/authors the option let these users/authors set specific CC licensing terms on a post by post basis.”

How it works:
It uses the CC api and the JsWidget to add a new section to the write/edit post page and then displays a small CC graphic/button and text on your published posts for all to see. The widget lets you choose the appropriate licensing structure and then your choice is automatically saved to a custom field the next time you click “Save and Continue Editing”, “Save”, or “Publish”. Then, it uses the CC api (details-license-uri-uri) to call some javascript that displays a small graphic/button and some text linking back to the definitions for the license you have chosen. Jquery was used to insert the new CC license section to the write/edit post pages as well as to open/close the new section. I also had to use Jquery to fix the tooltips for the JsWidget. Lastly, this plugin is optimized so that it will add only 1 DB query (the cc_js_result_uri) to each post that has set a CC license and stores it to a custom field for that given post – whereas the wpLicense plugin seemed to use 3 seperate db queries to set the global licencing for the site.

Screenshots:
Check out the plugin in action.

Download:
Click on the following link to download the plugin: per-post-license_v.02.zip

Requirements:
1. This plugin has been testing and works on WP 2.3.x using the default theme (but it is still a work in progess / comments and suggestions are welcome).
2. Your web server needs either curl (most have it installed and it’s the default setting used in this plugin) or URL file-access enabled (to be able to run file_get_contents() instead of curl).

Install:
1. Unzip and Copy the per-post-license folder to your plugins directiory and activate it.
2. Add the template function (see next paragraph) to where you’d like the CC image/button and text to appear on your post (this might be the single.php or footer.php template file).
3. Go to the Write post page or Edit an existing post.
4. Look for the new section marked “CC License” and click the small “plus” sign to open the section.
5. Select “A Creative Commons license” and choose the appropriate licensing structure.
6. Save the post and You’re Done!

WP Template Function:
Add the following function to the WP template file (like single.php, or footer.php) to get the CC license to appear on your post.

< ?php if(function_exists('cc_insert_html')) { cc_insert_html($display=true); } /* get cc code */ ?>

Template Options:
Right now, there are only 2 options that you can use with the cc_insert_html() template function.
1. The first is the $display variable. [$display=true ---> will show the CC license , $display=false will not]
2. The second is the $use_curl variable [default is set to --> $use_curl=true , if you explicitly set $use_curl=false the plugin will revert to the php function file_get_contents() which is not always enabled on all web servers]

CSS styles:
Here is a sample style you can use to center, add padding and margins, as well as a horizontal dashed separator (you can ofcourse use any style you like). You would add this code to your style.css file in your template directory.
#cc_code { text-align:center; font-size:11px; width:450px; margin-top:25px; padding-top:25px; border-top:1px dashed #ccc; }
You could also just use inline css and replace the < div id="cc_code" > and add these styles directly – something like < div style="text-align:center; font-size:11px;" >.

To Do:
- get rss/atom feeds showing CC license
- possibly add CC to header (if appropriate)
- option to set per author licensing (for all an author’s posts)
- option to set global default license for entire site
- option to turn off graphic/button and just show text
- option to choose/add an existing licensing structure (other than CC) by providing a URL
- create another template function to gather and list all posts with CC licensing (by title)

Using Subversion with WordPress – Part 2: Maintaining Vendor Branches and Upgrading WP Core Files

elran — Fri, 01 Feb 2008 23:01:11 +0000

This article assumes you have already read, “Using Subversion with WordPress – Part 1: Creating Vendor Branches and Integrating your Existing Code“. In short, you want to use Subversion to track/maintain local versions of both WordPress code and your own internal project code, side-by-side, all in the same svn repository.

In the previously mentioned article we used WordPress version 2.3.1 as our initial vendor drop. The following procedure illustrates how to use svn merge to quickly upgrade WordPress core files from version 2.3.1 to version 2.3.2 – without losing your local changes – but could be used as a general outline for upgrading any version of WordPress provided you followed the steps discussed in Part 1. Note: Backup your files and database before attempting any of this. Also, although not strictly required, the following steps assume you have some kind of shell access (like ssh) and a command line subversion client (like svn).

Maintaining Vendor Branches -
To perform this upgrade, we check out a copy of our current vendor branch (which contains our WP 2.3.1 source code), and replace that code with the new WP 2.3.2 source code. So, we simply copy the new files on top of existing files and directories. The goal here is to make our current directory contain only the new WP 2.3.2 code, and to ensure that all that code is under version control. I use the svn export command to grab the WP 2.3.2 source code – but downloading and extracting the WP files manually works just as well.

1. Prepare Current and New Code
$ mkdir upgrade $ cd upgrade $ svn co http://svn.yourdomain.com/vendor/wordpress/current/ $ svn export http://svn.automattic.com/wordpress/tags/2.3.2/ â€¦

2. Copy, Resolve Conflicts, and Commit Changes
$ cd current [optionally, delete all files but NOT folders / dont delete .svn folders] $ cp -a ../2.3.2/* . $ svn status $ svn ci -m "commiting WP 2.3.2 vendor drop to current branch" $ cd ../../ $ rm -rf upgrade â€¦

3. Tag the New Version
Our current branch now contains the new vendor drop. We tag the new version (in the same way we previously tagged the version 2.3.1 vendor drop – in Part 1)
$ svn copy http://svn.yourdomain.com/vendor/wordpress/current \ http://svn.yourdomain.com/vendor/wordpress/2.3.2 \ -m "tagging WordPress 2.3.2" â€¦

4. Merge the Differences and Commit Changes
Checkout a copy of your current project (from Part 1 – we used the folder: “newproject”). Merge the differences between the tag of the previous version (WP 2.3.1) and the new current version into our main development branch. Type svn status to see what files were modified and resolve any conflicts. Run svn add and svn delete commands where appropriate. Commit the changes and our local version of WP will now been completely upgraded without over-writing or deleting any existing modifications we may have previously made.
$ mkdir newproject $ cd newproject $ svn co http://svn.yourdomain.com/branches/newproject . $ svn merge http://svn.yourdomain.com/vendor/wordpress/2.3.1 \ http://svn.yourdomain.com/vendor/wordpress/current . $ svn status $ svn ci -m 'merging WordPress 2.3.2 into the main branch' â€¦

That’s all there is to it!

And, best of all, every change made to your internal project code – including those made to WP core files – is now documented and tracked from within your own local version control system.

Note: Don’t forget to visit http://www.yourdomain.com/wp-admin/upgrade.php in your web browser once you’ve completed all of these steps to make sure any database upgrades get applied as well.

Using Subversion with WordPress – Part 1: Creating Vendor Branches and Integrating your Existing Code

elran — Tue, 29 Jan 2008 01:03:57 +0000

This article assumes that you’ve read the basic svn howto and the more specific one provided on the WP Codex but would like to try or need a setup similar to that described here on a page called: Vendor branches. In short, you want to use Subversion to track/maintain local versions of both WordPress code and your own internal project code, side-by-side, all in the same svn repository.

Scenario:
Let’s say you have an in-house web developement project that is built upon or otherwise dependent on the WordPress core files. This can be for something as simple as creating/customizing your own WP themes and plugins, or as complex as maintaining your own modified versions of WP core files, with additional components/modules, etc. The important thing is that you imagine a scenario where you are already using Subversion to commit changes/updates to this internal project of yours. However, a problem occurs whenever a new version of WordPress is released. You need to upgrade the WP core files whithout losing any of the custom modifications you’ve been making up until now. Ideally, you would like to apply (to your internal project) only the changes made to the upgraded WP core files without over-writing any of your own work.

Solution:

“The solution to this problem is to use vendor branches. A vendor branch is a directory tree in your own version control system that contains information provided by a third-party entity, or vendor. Each version of the vendor’s data that you decide to absorb into your project is called a vendor drop.” (quote)

So, in this case, the third-party entity or vendor, is WordPress. What we want to do is: absorb the WP code into our own project. The rest of this article is going to illustrate the concept of “vendor drops” as they would apply to this particular scenario and using WordPress as the third-party vendor. Some of the benefits of this method are described in the article that the previously mentioned quote came from. In addition, this article goes on to describe the exact same process (but in more general terms) in a section entitled: General Vendor Branch Management Procedure. Well, here is my “Specific Vendor Branch Management Procedure” for WordPress.

Vendor Branch Management – Description

“Managing vendor branches generally works like this. You create a top-level directory (such as /vendor) to hold the vendor branches. Then you import the third party code into a subdirectory of that top-level directory. You then copy that subdirectory into your main development branch (for example, /trunk) at the appropriate location. You always make your local changes in the main development branch. With each new release of the code you are tracking you bring it into the vendor branch and merge the changes into /trunk, resolving whatever conflicts occur between your local changes and the upstream changes.” (quote)

Our Setup -
Let’s use WordPress 2.3.1 as an example. A newer version of WP (2.3.2) was just released and we’ll be using that version in a follow-up article to show how you can maintain this setup across multiple WP version upgrades without losing your local changes. However, for right now, we’ll assume that this is your first vendor drop and that your current project is already using Subversion and is also built against WP 2.3.1. In theory, you could use this same procedure with any version of WP – just make sure to start with an initial vendor drop that is the exact same version of WP as the one your project is currently using. Remember, we are not upgrading WP yet. We are just importing the WP code into our existing subversion-based system, side-by-side with our internal project. Note: Backup your files and database before attempting any of this. Also, although not strictly required, the following steps assume you have some kind of shell access (like ssh) and a command line subversion client (like svn).

Creating Vendor Branches -

1. Download Vendor Source Code
$ mkdir workspace $ cd workspace $ svn export http://svn.automattic.com/wordpress/tags/2.3.1/ â€¦

2. Importing Initial Vendor Drop
$ cd 2.3.1 $ svn import . http://svn.yourdomain.com/vendor/wordpress/current \ -m "importing initial WordPress vendor drop" $ cd ../ $ rm -rf 2.3.1 â€¦

3. Tagging Initial Vendor Drop
$ svn copy http://svn.yourdomain.com/vendor/wordpress/current \ http://svn.yourdomain.com/vendor/wordpress/2.3.1 \ -m "tagging WordPress 2.3.1" â€¦

4. Copying Vendor Drop into a New Branch
$ svn copy http://svn.yourdomain.com/vendor/wordpress/2.3.1 \ http://svn.yourdomain.com/branches/newproject \ -m "bringing WordPress 2.3.1 into the new branch" â€¦

5. Check Out and Add Customizations
We check out our project’s new branch – which now includes a copy of our first WP vendor drop – and we begin customizing or re-applying any changes to the code. Unless you’re starting from scratch, this probably just involves copying over any files and folders that were previously a part of your internal project code. Since we made sure to import the exact same version of WP that was used in our in-house development (this is not an upgrade) – there should be no conflicts and fewer surprises.
$ mkdir newproject $ cd newproject $ svn co http://svn.yourdomain.com/branches/newproject . $ cp -a /path/to/your/oldproject/* . â€¦

6. Resolve conflicts and Commit Changes
Type svn status to see what files were modified and resolve any conflicts. Run svn add and svn delete commands where appropriate. Commit the changes and our modified version of WP is now completely integrated into our in-house project.
$ svn ci -m "commiting changes into the new branch" $ cd ../ $ rm -rf newproject â€¦

That’s It! You’re Done.

At this point you might be thinking to yourself: “Well, that’s not exactly a time saver.. now is it?” And, you’d be right! But we won’t stop there! With WordPress integrated into our in-house versioning system – we can now use svn merge to quickly perform WP upgrades on our internal project code without risk of ever deleting or over-writing our own work.

And, best of all, every change made to your internal project code – including those made to WP core files – will now be documented and tracked from within your own local version control system.

[ Be sure to check back for the follow-up article entitled: "Using Subversion with WordPress - Part 2: Maintaining Vendor Branches and Upgrading WP Core Files" ]

WordPress 2.3 Plugin – ezmlm mailing list subscribe form

elran — Tue, 15 Jan 2008 21:15:18 +0000

ezmlm is a qmail-based mailing list manager written by Dan J. Bernstein.

From their site: “It has all the basic functionality of a mailing list manager, such as subscriber address management including automated bounce handling as well as message distribution and archiving. Its purpose is to efficiently send a message to a large number of recipients with minimal delay. It allows automated additions and subtractions from the subscriber database.”

i have seen it installed as the default built-in mailing list software for some shared hosting providers.
i needed a way to let visitors subscribe/unsubscribe to the ezmlm mailing list directly from a webpage.
but, when i searched the web for any existing WordPress plugins that could do this – i could not find any.
so, i thought there might be some wordpress users or admins that want to integrate ezmlm with their website using a standard web-based html signup form and some php magic.

description:
This plugin will allow visitors to subscribe and unsubscribe to your ezmlm mailing list – directly from your website – without having to manually send an email from their email client.

tested with WordPress 2.3.x
tested on Superb Hosting, and ezmlm mailing list software.

features:

basic error and spam checking built right into the plugin.
automatically prints out a “Thank You” or “Error” message on submit
you can use css to style the submit form to your heart’s content.
works even when your ezmlm is on a different server than you web server.
choose between using a standard text button or an image as your submit button.
choose between using the defulat privacy message, a custom message, or no message at all.

download:
ezmlm subscribe form v1.0

basic install:

download the plugin file, place it in the plugins directory, and active the plugin.
configure the plugin by going to Options > ezmlm signup form (see below for more details).
add the following code to your theme where you would like the ezmlm subscribe/unsubscribe form to appear.

< ?php if( function_exists('ezmlm_submit_form') ) { ezmlm_submit_form($display = true); } ?>

ezmlm options:
There are only 4 configuration options so far..

Set the Name of your mailing list (for example, you would enter: newsletter, if your mailing list was at: newsletter-subscribe@yourdomain.com)
Set the Domain of your mailing list (for example, you would enter: yourdomain.com, if your mailing list was at: newsletter-subscribe@yourdomain.com)
If you want to use an Image as the submit button: Enter the full URL to the image file (URL format: http://www.yourlocation.com/path/to/image.jpg – leave this blank and the form will use a standard text submit button)
If you want to set a custom privacy message: Enter it in the textarea provided (Or, type: DEFAULT and the default message will be displayed. Or, leave this area blank to have no privacy message displayed at all. Hint: you can use html in here too.)

screencap:

advanced usage:
- Template Tags –
To place ezmlm signup form on a specific page – like page 408 – add the following code to your page.php template file.
< ?php if(is_page(408)) { if( function_exists('ezmlm_submit_form') ) { ezmlm_submit_form($display = true); } } ?>

- Custom CSS -
You can style the signup form by adding the following IDs to your style.css file.
#ezmlmform (is the ID for the entire form)
#urlsubmit (is the ID for the image upload button)
/* example usage */ #ezmlmform { border:1px solid #000; padding:5px; }

credits:
Much of this code was borrowed from a forum thread called: ezmlm php subscribe/unsubscribe form
Documented here: http://forum.qmailrocks.org/showpost.php?p=16649&postcount=2.

VMTN Virtual Appliances – the 52 that looked interesting to me

elran — Tue, 16 Jan 2007 19:31:44 +0000

I have been using vmware for a while now..
Recently, i got sucked into the VMware Technology Network (VMTN) site – again – and browsing through the many virtual appliances available for download, i managed to compile a list of 52 of my favorites.
All you need to do is download the free VMware Player, which will let you run one of these virtual appliances on any Windows or Linux desktop.
Great for testing, coding, and learning. You can read more about virtualization on the VMware site.

The List of 52 Appliances (in no particular order)