Web development requires the hardware and software to accommodate a wide variety of client needs and web technologies. Apple has provided web developers with an enormously flexible development environment in Mac OS X. By including Apache, the world’s most widely used web server, along with a host of related technologies (PHP, OpenSSL, SSI, etc) Apple has provided a perfect compliment to popular tools such as BBEdit, Adobe Photoshop, and Macromedia Dreamweaver.

This tutorial will show you how to enable one of the most important technologies included with the standard installation of Apache on Mac OS X, mod_ssl. The mod_ssl module lets Apache use OpenSSL, thereby enabling cryptographically protected connections to web servers via the Secure Sockets Layer (SSL) and Transport Layer Security. Though this is not a comprehensive tutorial on system security, if you enable mod_ssl you will add a layer of security to a Mac OS X machine’s Web Sharing feature.

For more on security in Mac OS X, see An Introduction to Mac OS X Security.

Why SSL?

Adding Apache support for mod_ssl is a great development step. You will be able to test scripts and applications in the most realistic environment possible prior to deployment to a staging or production server. This will help cut development time. It also permits access to your computer that is encrypted. Web applications served off of your Macintosh will be accessible in a secure way. So passwords passed to your machine via web-based forms will be hidden from packet sniffers. Data transmitted to a browser will also be encrypted during transit.

Definition of SSL

The Draft Specification for the SSL Protocol contains a good definition of SSL.

… Secure Sockets Layer(SSL V3.0) protocol [is] a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.

In other words, SSL enables client/server communications that are encrypted, providing security and privacy in communications. Additionally, with SSL, every server has a “fingerprint”, a means of identifying a specific server as being the source of any information returned through an SSL request.

SSL uses Public Key Cryptography, which uses Key Pairs — one private key, kept on the server, and one public key, distributed to clients requesting it. Data encrypted or “locked” with one key can only be decrypted, or “unlocked” with the matching key in the key pair.

What’s There and What’s Needed

To establish secure communications over the web via SSL you need the Apache server compiled with the Enhanced Apache API (EAPI), OpenSSL, and the mod_ssl module. Thankfully, Apple has provided all of the needed ingredients in Mac OS X. Moreover, you can find documentation for these products on a standard Mac OS X installation:

• The Apache Manual (http://localhost/manual)
• mod_ssl User Manual (file://localhost/Library/Documentation/Services/apache_mod_ssl/index.html)
• OpenSSL “man” pages (type man openssl in the terminal).

The one item you need to add is the sign.sh script that is distributed with the mod_ssl distribution. You can find more information on this on the FAQ.

If you know how to start the Terminal, run sudo, and edit the httpd.conf file that configures Apache, you’ll be in good shape. I like using emacs for editing text files, and have included the commands needed for working with emacs. Feel free to use pico, TextEdit, BBEdit, or whatever you know how to use.

The sudo command lets you temporarily become a “superuser”. Using it requires that you know the password of a member of the admin group. You can see the members of the admin group by checking NetInfo Manager (under /groups/admin).

Finally, as cryptography is an acronym-rich subject, it might be helpful to keep a good glossary of terms used in cryptography close at hand. In this article, you’ll come across the following acronyms:

• RSA: A commonly used Public Key encryption system developed by Rivest, Shamir, and Adelman.
• DES: Data Encryption Standard. A cipher commonly used in commerce. Triple DES (3DES) describes the process of encrypting data three times with two or three DES keys.
• PEM: Privacy Enhanced Mail. An e-mail cryptography protocol from the IETF.

Configuring SSL

The first thing you need to do is generate the keys and certifications for the server. This requires using the Terminal. For sanity’s sake, create a directory (Folder) on the desktop called KeyGen and change into that directory.

cd ~/Desktop/KeyGen

You can now create an RSA private key and a CSR (Certificate Signing Request) for your server. An important part of private key cryptography is making sure that the parties involved in a transaction are who they say they are. This is accomplished through a third party — a trusted Certificate Authority (CA). The CA issues certificates that identify the parties, and confirms that the keys are correct and are cryptographically “signed.” Generating the CSR is the cryptographical equivalent to filling out a passport application. The CA will return the certificate (like a passport) which is used for identification and authentication.

You’re going to be self-signing the keys, so you’ll also be creating a CA key for the signature. The keys and certificates you create are purely for testing purposes. If you need to set up a production server, you should send your CSR to a proper CA, such as Verisign, for signing.

To create the RSA private key, issue the following command:

openssl genrsa -des3 -out server.key 1024

You will be asked for a passphrase in the creation of this key. Do not forget this passphrase! You’ll have to do this all over if you forget the passphrase. You will need this passphrase later on in the process.

You have just created the “SSLCertificateKeyFile”, as it is called in the httpd.conf — a 1024 bit RSA key encrypted with Triple-DES in PEM format. You’ll be plugging this into the configuration file for Apache soon.

Now you’re ready to create a CSR (Certificate Signing Request), which is what you would normally send to a CA for signing. You’re going to sign it yourself.

openssl req -new -key server.key -out server.csr

You’ll be asked for some information when you start this. Most of it is pretty self explanatory, but one item, in particular, is not. Here’s what you’ll be asked for:

Country Name (2 letter code) [AU]: (enter your country code here)
State or Province Name (full name) [Some-State]: (Enter your state here)
Locality Name (eg, city) []: (enter your city here)
Organization Name (eg, company) [Internet Widgits Pty Ltd]: (enter something here)
Organizational Unit Name (eg, section) []: (enter something here)
Common Name (eg, YOUR name) []: (this is the important one)
Email Address []: (your e-mail address)

The entry for “Common Name” is the one that seems like it should be one thing, but is, in fact, another. For this entry, you want to enter your “Server Name” as it appears in your httpd.conf (which you’ll be modifying soon). As this is just a development environment, you can enter 127.0.0.1, which is the default IP for “localhost”. Now, keep in mind that using 127.0.0.1 is not the same as using “localhost”. The strings either match, or they don’t — Unix is like that.

Looking at your KeyGen directory, you should have this:

[localhost:~/Desktop/KeyGen] bob% ls -la
total 12
drwxr-xr-x    5 bob      staff         126 Sep 14 17:01 .
drwx------   38 bob      staff        1248 Sep 14 16:57 ..
-rw-r--r--    1 bob      staff         729 Sep 14 17:01 server.csr
-rw-r--r--    1 bob      staff         963 Sep 14 16:59 server.key

Now you need to create a CA for signing the key. The process is similar to what you’ve just done, but there are some differences.

The first thing you need to do is create a key for your CA. It’s just like your server.key – a Triple-DES encrypted, 1024 bit RSA key.

openssl genrsa -des3 -out ca.key 1024

Again, you’ll be asked for a passphrase, which, again, you should not forget.

Now you will create a self-signed CA Certificate using the RSA key you just made.

openssl req -new -x509 -days 365 -key ca.key -out ca.crt

You’ll be asked for the passphrase for the key you just made, and, again, you’ll be asked to enter information about yourself. The main difference is that here, when you are asked for your “Common Name”, you want to enter your name — not the server name or IP address. This certificate is not associated with your server — it’s associated with you. It should look something like this:

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Texas
Locality Name (eg, city) []:San Antonio
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bogus CA
Organizational Unit Name (eg, section) []:Bogus CA for Dev
Common Name (eg, YOUR name) []:Bob Davis
Email Address []:bobdavis@mac.com

Now you have 4 files in your directory — a CA key and certificate, and a server key and certificate signing request.

The next step is the important one. This is where you sign the server.key with your ca.crt. This will provide the security assurance that browsers need to establish a secure connection. It provides the identification and verification part of the public key encryption system where the keys themselves provide the mechanism for the encryption and decryption.

The easiest way to do this is to use the sign.sh script contained in the mod_ssl source you downloaded (it’s in the pkg.contrib sub-directory) or wherever you put.

Copy the script to your working directory, make it executable, and then run it by issuing the following commands:

chmod +x sign.sh
./sign.sh server.csr

You should get something like this, but with the information you entered for the server.csr:

CA signing: server.csr -> server.crt:
Using configuration from ca.config
Enter PEM pass phrase:
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName            RINTABLE:'US'
stateOrProvinceName    RINTABLE:'Texas'
localityName           RINTABLE:'San Antonio'
organizationName       RINTABLE:'Testing'
organizationalUnitName:PRINTABLE:'Testing'
commonName             RINTABLE:'127.0.0.1'
emailAddress          :IA5STRING:'bobdavis@mac.com'
Certificate is to be certified until Sep 14 23:09:20 2002 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
CA verifying: server.crt <-> CA cert
server.crt: OK

For the questions “Sign the certificate?” and “1 out of 1 certificate requests certified, commit?”, you just need to type “y” (without quotes) and hit enter/return.

Looking at your working directory now, you’ll see that you have a number of new files and directories in KeyGen.

[localhost:~/Desktop/KeyGen] bob% ls -la
total 36
drwxr-xr-x   12 bob      staff         364 Sep 14 18:16 .
drwx------   38 bob      staff        1248 Sep 14 18:12 ..
-rw-r--r--    1 bob      staff        1298 Sep 14 17:55 ca.crt
drwxr-xr-x    3 bob      staff          58 Sep 14 18:09 ca.db.certs
-rw-r--r--    1 bob      staff         111 Sep 14 18:09 ca.db.index
-rw-r--r--    1 bob      staff           3 Sep 14 18:09 ca.db.serial
-rw-r--r--    1 bob      staff         963 Sep 14 17:52 ca.key
-rw-r--r--    1 bob      staff        2679 Sep 14 18:09 server.crt
-rw-r--r--    1 bob      staff         729 Sep 14 17:01 server.csr
-rw-r--r--    1 bob      staff         963 Sep 14 16:59 server.key
-rwxr-xr-x    1 bob      staff        1784 Sep 14 17:59 sign.sh

Now, make a directory in your /etc/httpd called ssl.key

sudo mkdir /etc/httpd/ssl.key

You’ll be prompted for your login password (you have to be in the admin group to use sudo), and the directory will be created.

Move all of the contents of your working directory to the ssl.key directory you just made. In a production system, it would be a very, very bad idea to keep your CA keys, certs and such on the server. If the security of the server is compromised, the ca.crt could be used to “sign” certificate signing requests on any machine. In other words, it gives anyone the power to impersonate you on the internet. Since you’re just using this for testing, and the certificates have bogus information in them, it’s not so terribly important. It is worth noting that this practice would be considered irresponsible on a server accessible to the outside world.

sudo cp -r * /etc/httpd/ssl.key/

One more step — and it’s another step that would not have a place in a production environment, but definitely makes life with your development system better: you’re going to remove the passphrase requirement from the server key by removing its encryption.

As things stand, when you start Apache, you will be prompted for a passphrase to read the private key. While this is fine for those who start and stop Apache manually from the command line every time, it does create some problems for those of us who have Apache (a.k.a. Web Sharing) start up automatically every time the system reboots. The system will hang on startup, patiently waiting for a passphrase that will never come — because there’s no way to enter the passphrase you’ve given the key! You’ll have to either boot into Mac OS 9 or boot into verbose mode to clear this problem if you forget.

Removing the pass phrase requirement is dangerous in a production environment, but acceptable for testing (especially if you enter information in your certificate request that makes it clear that this is a testing certificate, and not for production use).

Enter the following:

cd /etc/httpd/ssl.key
sudo cp server.key server.key.original
sudo openssl rsa -in server.key.original -out server.key

You’ll be asked for your passphrase for both the sudo command (your system passphrase) and the RSA command (the passphrase for the key). Comparing the two files server.key and server.key.original will show that they are now very different and that server.key.original contains a line stating, “Proc-Type: 4,ENCRYPTED”, that the decrypted file lacks.

Now, you have all of the files you need to make mod_ssl work with Apache. But you still need to configure the Apache server to use mod_ssl. Apple’s engineers have thoughtfully provided Apache compiled with EAPI, which allows modules to be included in Apache without recompiling the server. It makes it a lot easier to enable various modules as you need them.

Stop your web server if you haven’t already, either by using the Sharing control panel or through the command line using:

sudo apachectl stop

The file you want to edit is /etc/httpd/httpd.conf. The first thing you want to do is make a backup of the file. Keeping in mind that this directory is owned by root, you will have to use sudo for all of these commands. So, change directories to /etc/httpd and then make a copy of your httpd.conf.

cd /etc/httpd
sudo cp httpd.conf httpd.conf.backup

Now edit your httpd.conf file using the editor of your choice. I use emacs, so the instructions here are for emacs.

sudo emacs httpd.conf

First, you need to comment out the “Port” directive by placing a “#” in front of the line.

Port 80 should be changed to #Port 80. You will need to add the following just below where the Port directive was:

## SSL Support
##
## When we also provide SSL we have to listen to the
## standard HTTP port (see above) and to the HTTPS port
##

<IfModule mod_ssl.c>
		Listen 443
		Listen 80
</IfModule>

Adding these lines tells the server to be aware of traffic on port 80 (the standard HTTP port) and port 443 (the HTTPS port). This allows your SSL aware Apache installation to serve non-secure documents on port 80, while it is serving secure documents on 443.

Continuing on in the httpd.conf file, find the lines that reads:

#LoadModule ssl_module         libexec/httpd/libssl.so

and a little further down:

#AddModule mod_ssl.c

You need to remove the comments (#) to activate these lines. You can quickly search for these lines by using CTRL + s (in emacs) and typing “ssl”.

The two lines should now look like this:

LoadModule ssl_module         libexec/httpd/libssl.so

AddModule mod_ssl.c

Now find the “ServerName” directive and make sure it has 127.0.0.1 for it’s entry.

ServerName 127.0.0.1

Finally, just below the last line of the current httpd.conf, enter the following information which covers some of the global SSL directives and the specific directives for the port based virtual hosts.

<IfModule mod_ssl.c>
# Some MIME-types for downloading Certificates and CRLs
  AddType application/x-x509-ca-cert .crt
  AddType application/x-pkcs7-crl .crl

# inintial Directives for SSL

  # enable SSLv3 but not SSLv2
  SSLProtocol all -SSLv2
  SSLPassPhraseDialog builtin
  SSLSessionCache dbm:/var/run/ssl_scache
  SSLSessionCacheTimeout 300
  SSLMutex file:/var/run/ssl_mutex
  SSLRandomSeed startup builtin
  SSLLog /var/log/httpd/ssl_engine_log
  SSLLogLevel info
##
## SSL Virtual Host Context
##
<VirtualHost 127.0.0.1:80>
  #Just to keep things sane...
    DocumentRoot "/Library/WebServer/Documents"
    ServerName 127.0.0.1
    ServerAdmin bobdavis@mac.com
    SSLEngine off
</VirtualHost>
<VirtualHost 127.0.0.1:443>
  # General setup for the virtual host
    DocumentRoot "/Library/WebServer/Documents"
  #ServerName has to match the server you entered into the CSR
    ServerName 127.0.0.1
    ServerAdmin bobdavis@mac.com
    ErrorLog /var/log/httpd/error_log
    TransferLog /var/log/httpd/access_log
  # SSL Engine Switch:
  # Enable/Disable SSL for this virtual host.
    SSLEngine on
    # enable SSLv3 but not SSLv2
	SSLProtocol all -SSLv2
    SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
  # Path to your certificates and private key
    SSLCertificateFile /etc/httpd/ssl.key/server.crt
    SSLCertificateKeyFile /etc/httpd/ssl.key/server.key
    <Files ~ ".(cgi|shtml|phtml|php3?)$">
      SSLOptions +StdEnvVars
    </Files>
    <Directory "/Library/WebServer/CGI-Executables">
      SSLOptions +StdEnvVars
    </Directory>
# correction for browsers that don't always handle SSL connections well
    SetEnvIf User-Agent ".*MSIE.*"
    nokeepalive ssl-unclean-shutdown
    downgrade-1.0 force-response-1.0
# Per-Server Logging:
# The home of a custom SSL log file. Use this when you want a
# compact non-error SSL logfile on a virtual host basis.
    CustomLog /var/log/httpd/ssl_request_log
    "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x "%r" %b"
</VirtualHost>
</IfModule>

At this point, save your document (CTRL-x CTRL-s) and close emacs (CTRL-x CTRL-c).

There are many directives you can add to the SSL configuration for your machine, including extended logging, restrictions on ciphers used, encryption levels, etc. Full documentation is included in the Apache documents provided with Mac OS X (/Library/Documentation/Services/apache_mod_ssl/index.html) or on-line at http://www.modssl.org/.

Now it’s time to start your SSL enabled web server. You have the option of using either the command line or the Sharing control panel to start your web server. Since you have removed the passphrase requirement from your server key, it’s very simple. Either start Web Sharing from the control panel, or type either of the following lines into the command line:

sudo httpd -D SSL
sudo apachectl start

You will be asked for your system password, and you’ll get the output of Apache starting. It’s that simple. If you have Web Sharing set to start at startup it will start normally (this is why we removed the passphrase requirement).

Now test your installation using the browser of your choice by trying to access https://127.0.0.1/. Netscape 6 and Safari provide more information and allow you to accept unknown Certificate Authorities very easily. Microsoft’s Internet Explorer 5.x still has issues with unknown certificate issuers and will fail authentication.

Using Netscape, you’ll see the little open lock in the right corner has become a closed, illuminated lock. Success! You have enabled mod_ssl in your Mac OS X development environment.

Mention of non-Apple products or services is for informational purposes only. Apple assumes no responsibility with regard to the selection, performance, or use of these products.

If you don’t belong to the cult of Mac, you might ignore the release of Apple’s new OS X Server 10.5, codenamed Leopard. That would be a shame, particularly for small and midsize enterprises, including those with mixed Apple and Windows clients, or even all-Microsoft shops.

Stop snickering. Apple produces a pretty decent server operating system and server hardware. We chased Leopard around our Real-World lab and came away pleased on most fronts. This new server OS is ready for work. The e-mail platform connects to Active Directory and bundles AV and anti-spam software without pesky client access licenses. A spiffed-up calendar application can serve as a group scheduler. VPN services can host 500 users per Intel Xserve. In a first for Apple, IP failover provides high availability, and TimeMachine enables easily deployed server-based client backup. Leopard Server can even mimic an NT domain controller.

Everyone knows Mac is great for creating multimedia. Leopard maintains that reputation, and also makes it easier to distribute content online, including audio, video and photos.

On the downside, Leopard sometimes keeps things too simple. For instance, the calendar service and Web hosting are easy to set up and configure for one-server shops, but may require serious tweaking to function in more complex environments. When hiccups occur during setup or management, experienced administrators may find the built-in help and product documentation lacking. Apple also stumbles with a RADIUS deployment that’s only checked out for Apple Airport.

Get To Work

Apple says it wants to make Leopard a viable option for SMEs and workgroups in larger organizations. To that end, the Leopard dev team significantly overhauled OS X’s mail server, named Mail (wonder how long it took to think up that one). Leopard improves the client interface and offers ClamAV, SpamAssassin and SSL/TLS to boost security on the server end. Setup and configuration are fairly straightforward when integrated with Apple’s native Open Directory and LDAP, and Apple’s directory services can mimic an NT domain controller via Samba 3 for Windows clients, and/or connect to an existing Windows Active Directory.

OS X’s long-in-the-tooth calendar app, iCal, has graduated from single-user productivity tool to group scheduler and is now CalDAV-, iTIP- and iMIP-compliant. iCal supports robust scheduling options for users, groups and other resources listed and tagged in your corporate directory. Anyone familiar with Google Calendar will feel right at home with iCal. While the Exchange team probably isn’t getting nervous, these upgrades represent a huge leap for Apple in the corporate marketplace and are a solid platform for future development.

Also of note, Mail and iCal Server are free in 10.5, with none of the client-access licenses that Exchange requires. Is anyone outside of Cupertino going to run an enterprise messaging system on iCal and Mail? Probably not. Should a SME look to Leopard as a messaging platform on top of an Apple client base, a mixed Mac/Windows environment or, dare we say it, for a Windows shop? Yes. The price is right, and installation and management are simple.

Apple knows most folks (and IT shops) buy Macs in part for media creation and editing. The iLife suite bundled with every Mac client offers robust photo, video, audio, Web and DVD editing and publishing tools. Leopard has a number of complementary server-side applications to leverage iLife output in the enterprise. Past versions of OS X server bundled Mac-tuned Apache Web servers and other open-source ports for fairly straightforward Web and application hosting. Leopard does a much better job of simplifying the setup and administration of Web services.

And just as iLife simplifies media production on the client end, Leopard’s integrated Web services, Wiki Server, Quicktime Streaming Server, iChat/Jabber server and Podcast Producer simplify distribution of content. Podcast Producer absorbs feeds from client Macs, processes audio and video, and serves content in a variety of formats. This is neat stuff for a number of reasons: It streamlines content creation, centralizes media repositories, and simplifies the user experience. Podcast Producer is Xgrid-enabled, allowing the Leopard server to bring idle networked Macs into a distributed-computing grid to share the processing load. It’s render-farm technology brought to the masses.

We built and tore down a number of Web servers, collaborative wikis, and department file shares. We load tested a quad-core Xeon Xserve with twenty real simultaneous Mac and Windows clients against a “departmental” wiki-share and Mail server and barely impacted CPU utilization. We tied Leopard to an existing Open Directory/OpenLDAP with 500 users. We auth’ed a Leopard server to Kerberos. Everything worked just as expected from a network integration perspective.

Leopard’s initial setup from DVD or network image offers basic choices: Do you want this server to be a basic, workgroup or advanced server? What services do you want to host? Startup helpers load all required services based on your choices at installation, while the streamlined Server Preferences app simplifies management of key services once you’re up and running. Basic and workgroup configurations offer a streamlined server management application that is almost maddeningly simple for experienced administrators—on/off toggles with minimal configuration options.

The look and feel of the user interface mirrors Leopard client, with more animations, a revised dock, and a number of minor tweaks designed to simplify the look and feel of OS X. Overall this works, especially the automatic clean-up tools that organize the desktop and pop-up animations for dock folder contents. We like the evolutionary changes, and we were surprised at how much we grew to enjoy cover-flow browsing of network resources.

Apple offers both a system preloaded with the new OS, or the standalone software. Apple’s current Xserves (the company’s name for its server appliances) are a surprisingly good deal: Two dual-core 64-bit Woodcrest Xeons in a base configuration are bundled with an unlimited client 64-bit server OS for under $3,000. It’s all wrapped in a pretty 1U case to boot. Apple has come a long way from pushing over-priced dual G4 Xserves at educational clients.

If preloading isn’t to your liking, Apple says its new server OS will run on any Intel or PowerPC G5 server or desktop Mac, and on any G4 Mac clocked at 867MHz or faster. A gig of RAM and 20GB of drive space are your other ticket to the party. Based on our experience, stick with dual-G5 or multi-core Intel Macs with 2GB RAM or better. Lower spec machines will run file or basic network services under Leopard, but will cripple the full feature set.

And let’s get one thing clear: Leopard server needs a Mac hardware platform to run; you should not try to run OS X on an extra Dell box. All efforts of the OSX86 project aside, you will end up frustrated and dissatisfied with the results.

The installation DVD contains 32- and 64-bit code for Intel and PowerPC Mac platforms. In fact, every in-place build of Leopard is 32/64 and Intel/PPC. To test Apple’s claims, we built a server on a dual G5 server using an external Firewire drive as our boot partition. We then successfully booted and ran Leopard from the Firewire drive on a six-year-old dual G4 Xserve and a 13″ Macbook (32-bit platforms) and Xeon and G5 Xserves for 64-bit goodness. All platforms had wildly different hardware configurations, yet the OS ran without a single issue on each box, all server functionality intact.

Anyone out there willing to try that with Windows 2003?

Seeing Spots

One major knock against the new OS is that the built-in RADIUS service is vetted to support only Apple Airport base stations, though it is based on the open-source FreeRadius. You may get other APs to connect, but this is a significant gaffe if Apple is really serious about positioning Leopard for more than just Apple shops. Owners of PowerPC-based servers hoping to ramp up their podcasting will also be disappointed. It seems Podcast Producer is not universal; the server app is Intel-only due to Apple’s decision to go with the hardware acceleration in the Quartz-Extreme video chipset offered on all Intel Macs.

And despite the dead-simple installation, not everything was smooth sailing. Though iCal was a breeze to set up when we built a single-server “workgroup” configuration on a dual G5 Xserve with 2GB of RAM, we ran into hurdles elsewhere. For instance, we tried to configure iCal on a quad Xeon box configured as a member server in a Mac OS X 10.4 (Tiger) Open Directory environment. We couldn’t get iCal running without forcing a trusted bind back to our directory master.

We found this solution trolling the Apple support boards. We also found an alternate solution: a command-line edit of /etc/caldavd.plist that we didn’t have time to test in prep for this review. Two points to take away: We needed to go to the command line on a Mac, and our solution came from the user community. Linux users will appreciate the irony.

Finally, we lost access to one of our test platforms when we “demoted” it from a stand-alone directory master to being a member server. We were able to log in via network-based user accounts, but we were unable to administer the box. We ended up paving the installation. Apple rightly pointed out that most users would not be faced with our situation, and that Apple’s response would most likely be to rebuild, which we did.

On the whole, this is a substantial upgrade to Apple’s server offering, and we recommend shops running 10.4 to investigate. We also think non-Apple SMEs should take look, whether as a mail server, for collaboration or to facilitate the creation and distribution of multimedia content. OS X 10.5 Leopard is $499 for 10 clients, and $999 unlimited.

Joe Hernick is a contributing technical editor with InformationWeek and Network Computing. Write to him at jhernick@nwc.com.

Of the many options out there, many people choose to run their own blogging software as opposed to a managed service like Blogger or TypePad. On the software side, there are many decent tools available, such as Six Apart’s Movable Type (we have a tutorial for installing MT as well). WordPress is another mature, capable and free blogging engine that is very popular with many bloggers (like its founding developer, Matt Mullenweg) and rapidly gaining in popularity across the Web. WordPress is an excellent choice for a personal or professional blog, and the price is right, too. This tutorial will show you how to install WordPress 1.5.1.3 on OS X 10.4 Tiger.

Note: The most recent version of WordPress is 1.5.1.3, which contains a security patch among other improvements. This tutorial is fully compatible with the most recent version of WordPress. Version 1.5.1.3 is recommended for all WordPress users (upgrade instructions).

If you have installed another blog engine such as WordPress or Movable Type already, you may already have MySQL and/or PHP configured. If this is the case, you can skip right down to step 4.

Before we get started, let’s summarize what we’ll be going over in the installation:

1. Downloading and Installing WordPress 1.5.1.3
2. Enabling Personal Web Sharing
3. Downloading and Installing MySQL
4. Configuring MySQL
5. Enabling and Testing PHP
6. Configuring WordPress
7. ???
8. Profit!

Downloading and Installing WordPress 1.5.1.3

If we’re going to blog our way to stardom, we’ll need some blogging software, right? The first step we’ll take will be to download the latest stable version of WordPress, version 1.5.1.3. The compressed file should be about 250KB, and OS X will decompress it for you.

Once it’s decompressed, we’ll move the wordpress directory to OS X’s Web hosting directory in /Library/WebServer/Documents. By default, all requests for the domain’s root directory (like http://maczealots.com/) will go to this directory. This can be changed in Apache’s httpd.conf file, which we’ll cover later. If you like, you can also change the name of the wordpress directory to something else, like blog. This way the URL of the blog would change to http://www.yoursite.com/blog/ Additionally, if you want the blog itself to be at the root directory, delete all the items from the /Library/WebServer/Documents directory and move the contents of the wordpress directory to the now-empty Documents folder.

Enabling Personal Web Sharing

“Personal Web Sharing” (PWS) is Apple’s marketing name for Apache, the industrial-strength, tried-and-true Web server du jour. When you enable PWS, OS X starts up Apache, registers the modules, opens ports, etc. Since we’ll be serving the blog, we’ll need to have Apache running.

To enable Personal Web Sharing, open the Sharing preference pane in System Preferences. Check the box labeled “Personal Web Sharing”, and that’s it. (You may have to authenticate as an administrator before it will let you enable anything.) Go ahead and close System Preferences; you’re ready to install MySQL now.

Note: We are working on a version of this tutorial that includes the ability to host the database with SQLite, which is prepackaged in OS X 10.4. However, support for SQLite in WordPress is still being fully developed, so for now MySQL is still the way to go. If you’d like to see such an article, let us know.

Downloading and Installing MySQL

MySQL is the database backend that WordPress (and other blogging packages like Movable Type) can use to store blog entries, users, comments, etc. MySQL is free for personal use. First, download MySQL (4.0.24 at the time of publication). It will come as disk image with two packages and a readme. We will be installing both packages. First, open the main MySQL installer. It will install all the necessary components to run MySQL onto your OS X volume. After that installer has completed, run the startup item installer, which will automatically start up MySQL after any computer restarts.

Note: One of the most common problems reported is that people install MySQL 4.1 instead of 4.0. I can understand the desire to be on the bleeding edge of software, but WordPress (and most other blog/CMS engines) use an older authentication scheme that is incompatible with MySQL 4.1 and greater. There are hacks and workarounds out there, but for the easiest installation, stick to MySQL 4.0.

Configuring MySQL

Now that you have installed MySQL, let’s configure it so WordPress can access it. Open a new terminal session (found in /Applications/Utilities/Terminal.app) and type the following commands to navigate, make some changes, and start the MySQL daemon:

cd /usr/local/mysql
sudo chown -R mysql data/
sudo echo
sudo ./bin/mysqld_safe &

Next, let’s launch MySQL and use the test database (called test, even) to make sure everything’s running correctly:

/usr/local/mysql/bin/mysql test

If everything’s running correctly, you should see output similar to this:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version 4.0.24-standard

Type 'help;' or '\h' for help.  Type '\c' to clear the buffer.

mysql>

Once you’ve verified that MySQL is running correctly, use the command quit to return to the console prompt.

Now that MySQL is running, we’ll change the root password of MySQL so that WordPress (and you) can access it later. Use this command (where yourpasswordhere is replaced by your chosen password):

/usr/local/mysql/bin/mysqladmin -u root password yourpasswordhere

The last thing we’ll have to do in MySQL is to create a table for WordPress to store its data. We’ll call it wordpress to keep things simple. To accomplish this, we’ll enter MySQL, create the table, and allow WordPress to edit it.

/usr/local/mysql/bin/mysql -u root -p
CREATE DATABASE wordpress;
quit

Enabling and Testing PHP

Now that MySQL is ready to go, let’s fire up PHP. OS X ships with PHP installed, but not activated. Fortunately, this is really easy to do. The only file we’ll need to edit is httpd.conf, which Apache uses for its configuration.

Open the config file in your favorite editor (I’ll be using pico):

sudo pico /etc/httpd/httpd.conf

Mosey on down to the Dynamic Shared Object (DSO) Support section. It’s the one with all the LoadModule listings. The one for PHP 4 is towards the bottom of that list. Look for the line and uncomment it to activate it. You can uncomment a line by removing the pound symbol (“#”) from the beginning of the line. The new line should look as such:

LoadModule php4_module

We’ll also need to uncomment the PHP 4 entry in the AddModule listings, so that it looks as such:

AddModule mod_php4.c

Once those two lines are edited you can save the httpd.conf file and quit the editor. Since we’ve edited Apache’s load setup, we need to restart Apache so it will recognize the changes:

sudo apachectl graceful

With that out of the way, let’s make sure that PHP is indeed running. Create a new text file in your favorite editor (stay away from RTF-happy TextEdit, though – SubEthaEdit gets my vote) and fill it with the following text:

<?php
phpinfo();
?>

Save the file as test.php in the root directory (/Library/WebServer/Documents/) and load the address of the page (usually http://localhost/test.php) into a Web browser. If PHP was correctly enabled, the phpinfo(); command should output page after page about the PHP installation. If not, retrace your steps – it can be easy to make a mistake.

Configuring WordPress

Now for the last step: configuring WordPress. First, you’ll need to edit WordPress’ default configuration file wp-config-sample.php. You’ll find it in the root folder of the WordPress installation. This is where you’ll set up the database information. Edit the following settings:

define('DB_NAME', 'wordpress'); – Change ‘wordpress‘ to the name of the database you created in MySQL (in the example we named it wordpress).
define('DB_USER', 'username'); – change ‘username‘ to root.
define('DB_PASSWORD', 'password'); – change ‘password‘ to the MySQL password you chose.

Once you’ve made the changes, save the file as wp-config.php in the same directory and delete wp-config-sample.php.

Now, open a Web browser window and start the WordPress installer, found at http://localhost/blog/wp-admin/install.php. (Remember that if you chose to install WordPress in a different directory, such as the root directory, the address will be different for you.) WordPress will take you through the install process and set up the database with all the tables it needs to run.

After it completes, it will give you the login (admin) and password to log in to WordPress. The password is randomly generated and not recoverable so please write it down!

After you log in, there are two things you need to immediately do. First, change your password to something you can remember. You can find it in the Users tab of WordPress’ controls. Also, to avoid posting entries as “Administrator”, you can either create another account with a posting name, or simply enter a nicknaame in the admin account. But whatever you do, change the password and remember it — once you lose it, your data is hard to get back.

Now comes the moment you’ve been waiting for. Click View site » in WordPress’ controls or open a Web browser and go to http://localhost/blog and watch your blog appear! Roll up your sleeves, perfect the CSS, and wax poetic, serving it to the free world without spending a dime on extra software. Happy blogging!

by Joel Rennich, mactroll@afp548.com

The purpose of this article is to give you an idea of what you can do with SSL in Mac OS X Server and how you can use that to secure as many services as possible. So, first we’ll talk some about SSL in general and how to create the certificates, then we’ll discuss what to do with those certificates.

SSL certificate creation

Before we start I’d like to point out that we are going to be creating home-rolled SSL certificates here. As such you will run into problems when connecting to your Server using applications like a Web browser. Most applications will allow you to ignore the fact that your certificate hasn’t been validated by one of the internationally recognized certificate authorities, but it’s still a pain.

I’ll show you how to get around that by importing in your own certificate authority onto your client machines. This presumes that you have control over all of your clients, so for internal use where you control both the server and the client setups being your own certificate authority is great. If you plan on doing business with the general public, such as using it for credit card processing on a Web page, I would strongly recommend that you invest the money in a “real” certificate.

If you do buy one at least take a look at www.qualityssl.com. They have really good prices and are Mac-based, so you can keep it in the family.

Also all of the openSSL work, such as generating and signing certificates, can be done on Mac OS X client.

1. Make a certificate authority (CA).

This should be done in a secure place, since if your CA gets compromised then all of your security goes out the window. A decent place for this would be on your most secure server or on your own machine.

It doesn’t matter where on the filesystem you do this; however, I personally prefer to create a CA directory in /etc:

sudo mkdir -p /etc/certs
cd /etc/certs

Right now this folder has fairly relaxed permissions on it. As soon as were done we’ll change that to greatly limit access to the folder. Now that we have our place we need to begin generatng the CA. We do this by making a certificate signing request (CSR). This example will generate a 3DES encrypted 2048 bit key. This is a rather high security key which means it takes longer to process. So if you feel the need you can scale it down to 1024 bits if you like. Although I haven’t had any problems using this with Mac OS X 10.2 and Windows 2000.

openssl genrsa -des3 -out ca.key 2048

You will be asked for a passphrase for this key. You need to both remember this phrase and keep it secure. Your entire SSL system will depend on this passphrase being secure.

Now that you have the request you can sign it into a CA.

openssl req -new -x509 -days 4096 -key ca.key -out ca.crt

You’ll be asked for the passphrase that you just set up. After that your certificate authority will be valid for 4096 days.

You now have a full blown certificate authority for your machine. From this we will base all of your other certificates from it.

2. Generate a certificate for your server.

You will need one for each domain that you have; i.e., mail.afp548.com and www.afp548.com will each need one if you want to secure both sites.

So first we will generate a new private key.

openssl genrsa -des3 -out server.key 1024

You will be prompted for a password here also. This should be different from the password for the CA. Just remember it because you will need to enter it into Server Admin to get SSL running.

Now you need to generate a request with the private key.

openssl req -new -key server.key -out server.csr

Again you will be asked for a password. This is the one you entered in the step above. Then you will get a bunch of questions. They all really don’t matter except for common name. This needs to be the fully qualified name of your Web server, like www.afp548.com. If this is wrong you will get errors in the browser. Also: leave the challenge password blank.

Now we need to set up a few folders so that we can actually sign the certificate.

mkdir -p demoCA/private
cp ca.key demoCA/private/cakey.pem
cp ca.crt demoCA/cacert.pem
mkdir demoCA/newcerts
touch demoCA/index.txt

            echo “01” > demoCA/serial

You can now actually sign the server certificate with your newly minted CA.

openssl ca -policy policy_anything -in server.csr -out server.crt

The password you are prompted for is the password you assigned to the CA, the first one, not to the certificate itself. If you need to create more certificates you will only need to do the last three steps for each.

Finally to keep things secret and to keep things safe, change the permissions on this folder.

sudo chmod 700 /etc/certs

Now you can take all of your pieces and make the sites secure.

3. Securing your web site.

Go into Server Admin and make sure that the SSL module is enabled in the modules pane under settings.

Then go to the site that you want to secure. Change the port to 443, click on the security button, and enable SSL by checking the box at the top. Then you need to open up some of the files that you have created in TextEdit, or any text editor, and copy and paste them into the three appropriate spots. Copy server.crt into “Certificate File.” Copy server.key into “Key File,” and copy ca.crt into “CA File.”

Finally, you’ll want to enter the passphrase for the server certificate into the “Pass Phrase” field or else you’ll have to be at the server everytime it starts up.

A few parting thoughts about securing Web connections. You will need a separate IP address for every SSL site that you have. There’s a complicated reason for this, but it involves how SSL connections begin and I don’t know of any way around this. In 10.2 you had to edit the httpd_macosxserver.conf file to get higher level encryption. This requirement seems to be gone in 10.3 as it defaults to using all ciphers.

When you are done your certificates will be stored in /etc/httpd/ssl.crt and /etc/httpd/ssl.key. Your site’s specific config is stashed in /etc/httpd/sites/your site’s name. So look in there for any specific info. Also the passphrase that you used is stashed in /etc/httpd/servermgr_web_httpd_config.plist, which is root-readable only.

4. Securing LDAP

We run into a bit of a problem here. OpenLDAP doesn’t like a server key that has a passpharse associated with it. Postfix and Cyrus are going to be the same way. So remove the passphrase.

openssl rsa -in server.key -out serverno.key

Now go back into Server Admin. Select the Open Directory settings and go to the “Protocols” tab. Check the “Use SSL” box and then put the path to your certificates in the three fields.

Certificate: /etc/certs/server.crt
SSL Key: /etc/certs/serverno.key
CA Certificate: /etc/certs/ca.crt

OpenSSL runs as root, so it will be able to get into /etc/certs without any issues. As soon as you save this config Server Admin will restart OpenLDAP with SSL support.

The SSL configuration for OpenLDAP is stored in /etc/openldap/slapd_macosxserver.conf.

5. Securing SMTP

Postfix can be setup to use the same certificate as the one you established for openLDAP. However, it wants to have both the key and the certificate in the same file. This is easily done.

sudo cat /etc/certs/serverno.key /etc/certs/server.crt > /etc/certs/server.pem

Now link that file to what Postfix is looking for.

ln -s /etc/certs/server.pem /etc/postfix/

Now reload Postfix through the GUI or by doing this from the command line.

sudo postfix reload

And start using encrypted SMTP services.

The SSL configuration for Postfix is kept in /etc/postfix/main.cf.

6. Securing POP/IMAP

Cyrus can use the same certificate as Postfix, but it needs to be accessible by the cyrus user. That requires relaxing the permission a bit on the certificate store.

sudo chown :mail /etc/certs
sudo chmod 750 /etc/certs
sudo chmod -R 700 /etc/certs/demoCA

Now you can link the server.pem file into where Cyrus POP and IMAP want to find it.

ln -s /etc/certs/server.pem /var/imap/server.pem

Now go into Server Admin and set up POP/IMAP to use SSL in the Advanced button of the Mail Server settings.

Set your mail client accordingly and securely read your mail.

The SSL configuration for Cyrus is stored in /etc/imap.conf.

7. Enable your clients

Since your CA is self-signed all of your Mac OS X applications and services will yell at you for using it. You can get around this by adding the cert to the client’s x509 Anchors keychain. Essentially this is the root CA file for your machine.

Do this by copying over to the client machine the ca.crt file that you created in the first step. Then install it by doing

sudo certtool i ca.crt v k=/System/Library/Keychains/x509Anchors

Your client will now trust certificates that you have signed into being with this CA. If you do this right, you’ll use the same CA for all of your servers and their services. That way you’ll only have to import one file into the clients x509Anchors.

8. E-mail certs

This bit is for bonus points, but all the cool kids are doing it and so should you. Mail.app in 10.3 allows the use of s/mime certificates. These are PKI certificates that act similar to SSL certificates and can sign and or encrypt e-mail.

The easiest way for a personal user to get a certificate is to head over to www.thawte.com and sign up for their free community mail certificate. Really good instructions for this can be found here:

http://joar.com/certificates/

However, if for some reason you feel like making your own, read on. Note that this is mostly an exercise in what you can do with OpenSSL. Since the Thawte certificates are free and easily available you’re probably better off using them. However, if you want to outfit your entire organization with home rolled certificates, well here you go. Just be careful to only use this between users that have imported your root CA that you created.

To do this you need to first generate a certificate for your e-mail user. This is pretty much the same thing as generating one for a server.

openssl genrsa -des3 -out mail.key 1024

Give it a pass phrase to lock it up.

openssl req -new -key mail.key -out mail.csr

Here, you’ll want to use your real name for the Common Name. Joel Rennich is what I would use. Then make sure that you fill out the e-mail field with what you have set up in Mail.app as your e-mail address. Capitalization is important here. I would use “mactroll@afp548.com”.

Now sign this cert with your CA.

openssl ca -policy policy_anything -in mail.csr -out mail.crt

You’ll enter in your CA password and then commit the signature.

Finally you can convert the signed certificate into the format that is used for s/mime. When you do this it will first ask you for your mail certificate password that you set up a few commands before. Then it will ask you for an export password. This can be the same of different, it doesn’t matter, but you will need to use the export password when importing this certificate into your Keychain so you can use it with mail.

openssl pkcs12 -export -inkey mail.key -certfile mail.crt -in mail.crt -out mactroll.p12

This is your “official” e-mail certificate. Copy this over to your client machine and double-click. Keychain Access should launch and ask you for your export password. The certificate will then be imported into your keychain and immediately usable by Mail.app for the account that you specified in the e-mail field when you generated it.

9. Other odds and ends

When you sign your certificates with your CA openssl uses a default config file which can be found at /System/Library/OpenSSL/openssl.cnf. If you want to change any of the defaults go here. For example, certificates that you sign will only be valid for 1 year, unless you edit this file to change that.

Building a website is a complicated process, and testing your finished product on every possible browser can be even more daunting. However, because modern browsers such as Safari, Mozilla, and Internet Explorer 6 are compliant with the World Wide Web Consortium’s (W3C) standards, testing your pages with the W3C Validation Tool is a great way to ensure that your pages work with modern browsers. The W3C Validator provides a line-by-line level of feedback, such as error information with references to the standards, on any URL you submit or HTML file you upload.

But what if your pages are accessible only within your firewall? Or what if your organization is reluctant to have their pages submitted to any external site for validation—even if it’s fully automated? This article describes how you can host the same W3C standards validation service within the confines of your own network and security constraints. You just need to download a number of open-source components that are freely available, and then configure them properly. By following this recipe, you will have an internal validation tool that will not only be accessible to your web developers as needed, but can actually be integrated into your production process. You have the code—you can make it fit your workflow.

Validator Files

First be sure to have the Xcode Tools 1.5 or higher installed.

Besides the Xcode Tools, you need to download the validator and supporting files:
Base Code: http://validator.w3.org/validator.tar.gz
DTD Library: http://validator.w3.org/sgml-lib.tar.gz

Once you download these files, you need to decompress them, move them to the proper location, and set the permissions for the executable file. The above downloaded files will download to your downloads folder, ours was on the Desktop, as shown below. Do this in the Terminal Window. The following is an example of where to move the files to (assuming they were downloaded to your desktop).

Welcome to Darwin!
macosx:~ macosx$ cd Desktop
macosx:~/Desktop macosx$ tar xf validator.tar
macosx:~/Desktop macosx$ tar xf sgml-lib.tar
macosx:~ macosx$ cd /Library/WebServer/Documents
macosx:/Library/WebServer/Documents/ macosx$ mkdir validator/
macosx:/Library/WebServer/Documents/ macosx$ cp -R ~/Desktop/validator-0.7.0/ validator/
macosx:/Library/WebServer/Documents/ macosx$ cd validator/htdocs/
macosx:/Library/WebServer/Documents/validator/htdocs macosx$ cp ../httpd/cgi-bin/check .
macosx:/Library/WebServer/Documents/validator/htdocs macosx$ sudo chmod 755 check

Edit the validator.conf file

Now, edit the validator.conf file (located at /Library/WebServer/Documents/validator/htdocs/config/validator.conf) with your favorite text editor. Do not cut and paste from the example file below, this will create an invalid config file.

1. Change the ‘Maintainer’ email address on line 73 to your email address.
2. Change the ‘Home Page’ URL on line 77 to the correct URL for your installation.
3. Uncomment & change the base path of ‘/usr/local/validator’ to ‘/Library/WebServer/Documents/validator’ on line 24.
4. Change ‘SGML Parser’ from ‘/usr/bin/onsgmls’ to ‘/sw/bin/onsgmls’ on line 37, this is where Fink will install the OpenSP software later in these instructions.
5. Save the file.

Here is what our file looked like when we finished:

#
# Main Configuration File for the W3C Markup Validation Service.
#
# $Id: validator.conf,v 1.24 2005/07/08 08:31:09 ot Exp $
#
# See 'perldoc Config::General' for the syntax, and be aware that the
# 'SplitPolicy' is 'equalsign', ie. keys and values are separated by '\s*=\s*',
# and that 'InterPolateVars' is in effect.
#

#
# Base Path for Markup Validator files.
#
# You MUST set these unless you use the default locations for the files.
# e.g. the config files in "/etc/w3c/" and everything else in
# "/usr/local/validator/".
#
# Make sure all file paths below do NOT end with a slash

<Paths>
  #
  # Base path.  Defaults to the value of the W3C_VALIDATOR_HOME environment
  # variable or /usr/local/validator if the variable does not exist.
  Base = /Library/WebServer/Documents/validator

  #
  # Location of template files
  Templates = $Base/share/templates

  <SGML>
    #
    # The SGML Library Path.
    Library = $Base/htdocs/sgml-lib

    #
    # The SGML Parser to use.  Defaults to /usr/bin/onsgmls.
    Parser = /sw/bin/onsgmls
  </SGML>
</Paths>

#
# This controls whether the debugging options are allowed to be enabled.
Allow Debug = yes

#
# This lets you permanently enable the debugging options. Can be overridden
# with CGI options (unlike "Allow Debug" above).
Enable Debug = no

#
# Whether private RFC1918 addresses are allowed.
Allow Private IPs = no

#
# Whether the (highly experimental!) SOAP support should be enabled.
Enable SOAP = no

#
# Whether the validator will check its own output.
# 0 means it will refuse to check its own output, 1 means it will but it will
# refuse to check the results of it checking itself. Etc.
Max Recursion = 0

#
# Protocols the validator is allowed to use for retrieving documents.
# The default is to allow http and https.
<Protocols>
  Allow = data,http,https
</Protocols>

#
# Email address of the maintainer of this service.
Maintainer = web-dev@lists.apple.com

#
# The "Home Page" for the service.  Make sure this ends with a slash.
Home Page = http://localhost/validator/htdocs/

#
# Base URI for the Element Reference.
Element Ref URI = http://www.htmlhelp.com/reference/html40/

#
# Mapping tables etc...
#

#
# Maps element names to URLs (cf. "Element Ref URI" above).
<Elements>
  Include eref.cfg
</Elements>

#
# Main document Type Registry; contains all information on the types
# of documents we support and how they are processed.
<Types>
  Include types.conf
</Types>

#
# Mapping of charset names to their IANA names and how iconv(3) knows them.
<Charsets>
  Include charset.cfg
</Charsets>

#
# Map MIME Media Type to Parse Mode mapping.
<MIME>
  text/xml              = XML
  image/svg             = XML
  image/svg+xml         = XML
  application/smil      = XML
  application/xml       = XML
  text/html             = TBD
  text/vnd.wap.wml      = XML
  application/xhtml+xml = XML
  application/mathml+xml = XML
</MIME>

#
# Source for the "Tip of The Day" blurbs.
<Tips>
  Include tips.cfg
</Tips>

Once you have edited this file, you need to move it to the proper location. Again, do this in the Terminal Window, as shown below.

Welcome to Darwin!
macosx:~ macosx$  cd /etc
macosx:/etc macosx$ sudo mkdir w3c
macosx:/etc macosx$ cd w3c
macosx:/etc/w3c macosx$ sudo cp /Library/WebServer/Documents/validator/htdocs/config/*.* .

Edit the apache httpd.conf file

Now, edit the apache config file—this example uses the application pico—to tell apache some information about the validator; we again use the Terminal Window for this:

Welcome to Darwin!
macosx:~ macosx$ sudo pico /etc/httpd/httpd.conf

This opens the apache config file into the pico text editor. Scroll to the bottom of the file and add the following lines:

# This is the directory where you have the validator's "check"
# script as well as its and *.html, *.css etc files.

<Directory /Library/WebServer/Documents/validator/htdocs>
  Options              ExecCGI IncludesNOEXEC Indexes MultiViews
  AllowOverride        None
  AddHandler           server-parsed .html
  AddCharset           utf-8         .html
</Directory>

# Tell httpd that "check" is a CGI script.

<Location "/validator/htdocs/check">
  SetHandler           cgi-script
</Location>

Save the file by pressing Control-X and answering ‘Y’ to the prompt.

Now, restart personal web sharing from the Terminal Window:

Welcome to Darwin!
macosx:~ macosx$ sudo apachectl graceful

Install Fink & OpenSP

Install Open SP (this is needed in order for the validator to run). The easiest way to install Open SP is via Fink. Follow the Fink Installation Instructions for Mac OS X if you don’t already have Fink installed.

Once you have completed a full Fink installation and Fink selfupdate, then install OpenSP via Fink, using the Terminal Window:

Welcome to Darwin!
macosx:~ macosx$ Fink install openSP3

Installing the Necessary Perl Modules

The easiest way to install the required Perl modules is via CPAN. The W3C has provided a CPAN bundle that will install all the required Perl modules. If this is the first time you are using CPAN, you must first go through a configuration of CPAN. All the default answers to the prompts should be sufficient—just press the Return key at each prompt.

Open the Terminal Window and run CPAN:

Welcome to Darwin!
macosx:~ macosx$ sudo perl -MCPAN -e shell

After configuring CPAN, you get a cpan> command prompt. Now you are ready to install the bundle via CPAN as shown below. You will need to accept ‘recursively get missing modules’

cpan> install Bundle::W3C::Validator

Success!

Your validator should now be working now at http://localhost/validator/htdocs/ on your local Mac.

If you have any questions or comments, you can post to the Apple Web Development Mailing List.

This article was tested on Mac OS X (10.4). The original panther tested version of this article is located at http://developer.apple.com/internet/opensource/validatorpanther.html

MySQL has become one of the most popular databases for Web applications. The database is well suited for common Web-related tasks like content management, and for implementing Web features like discussion boards and guestbooks. For a time, some developers avoided MySQL for commercial applications because it did not implement certain features, such as transactions. But this is no longer the case, and MySQL is a great choice for just about any Web-based application.

In this article I’ll give you an overview of MySQL’s features and drawbacks, show you how to install MySQL on Mac OS X, and introduce you to some of MySQL’s notable technical aspects.

MySQL Features

Perhaps the most prominent feature of MySQL is its speed when running SQL SELECT statements. MySQL was built for speed. The core of the MySQL engine is very small and streamlined, and the default table type (a modified ISAM table) was designed specifically for running SELECTs quickly. If your application calls for the advantages of a relational structure but the database contents are relatively static — as is often the case with Web content — MySQL’s speed is a great advantage.

MySQL is also undeniably stable. In both your production and serving environments, you can be reasonably confident that MySQL will be up and processing queries as long as power flows to your machine.

Another important benefit is that MySQL is relatively easy to learn. Even if you’re new to relational databases, you can learn MySQL and create very sophisticated Web applications in a short period of time.

The popularity of MySQL is a benefit as well, because if you run into difficulty, you can lean on the active community that supports MySQL. There are many mailing lists dedicated to MySQL, and most questions find quick and thorough answers.

MySQL Drawbacks

If you are an advanced database user, you should be aware of some of MySQL’s limitations. MySQL’s implementation of standard query language is missing support for sub-selects, foreign key constraints (for some table types), stored procedures, and views. If you feel you need these features, you’re probably better off looking into PostgreSQL, FrontBase, or another database.

Lack of support for transactions used to be a drawback of MySQL, but this has been addressed. Now, on Mac OS X, you can use the MySQL InnoDB table type and have access to row-level locking and robust transaction support, as well as foreign key constraints.

Installing MySQL

If you’re running Mac OS X Server, you are in luck — MySQL is already there. Just go to Applications/Server/MySQL Manager to access it. If you are running Mac OS X Client, you’ll have to install MySQL. if you have already installed a version of MySQl and want to upgrade, I can recommend the upgrade instructions from http://www.entropy.ch. For a new installation, follow the Mac OS X installation instructions for the MySQL provided binary distribution ( a true Mac OS X installer package file) at http://dev.mysql.com/doc/refman/5.0/en/mac-os-x-installation.html and be done with it. However, sometimes you want to compile and install directly from the source, either because you are changing the default build settings, or you want the latest and greatest version before there’s a binary installer. The following will help you through that process.

When installing MySQL, you need to be aware of the potential effect this will have on the security of your system, as a database server can open an avenue of attack. In the example below, I show how to install MySQL on Mac OS X while maintaining the security of your system.

One basic security tenet is that of “least privilege.” In short, this means that everyone and everything should have only the privileges required for it to complete its task(s). Those privileges should be available for the least amount of time possible—ideally, once the task is completed, the privileges should be revoked.

I’m also choosing to build MySQL from source, rather than install a pre-built binary. This gives greater control over the installation, as you’ll see below.

Configuring and Compiling MySQL

I plan to install mysql in /usr/local/mysql. I also plan to locate the mysql UNIX socket under the /usr/local/mysql/ directory as /usr/local/mysql/run/mysql_socket so that it will be publicly available, but associated with the MySQL installation. Note that in a standard installation, the socket file would be placed in /tmp.

You can now download the source via a Web browser.

Once you have the source, you can pretty much follow the quick install directions from the mysql documentation pages, adding only debug support ( — with-debug) and the build environment comment ( — with-comment). The configure command should look like:

./configure --prefix=/usr/local/mysql
--with-unix-socket-path=/usr/local/mysql/run/mysql_socket
--with-mysqld-user=mysql --with-comment --with-debug

Once the configuration completes, running make, and then sudo make install, installs mysql in /usr/local/mysql. Running sudo /usr/local/mysql/bin/mysql_install_db --force adds the var/ space for databases and creates the default databases (mysql and test). You also need to add the run/ directory where the mysql UNIX socket will live, with sudo mkdir /usr/local/mysql/run. Once all of that is done, a directory listing should look like:

% ls -Fla /usr/local/mysql/
total 26
drwxr-xr-x 13 root wheel 1024 Jun 5 13:42 ./
drwxr-xr-x 11 root wheel 1024 Jun 5 12:19 ../
drwxr-xr-x  2 root wheel 1024 Jun 5 12:20 bin/
drwxr-xr-x  3 root wheel 1024 Jun 5 12:19 include/
drwxr-xr-x  2 root wheel 1024 Jun 5 12:19 info/
drwxr-xr-x  3 root wheel 1024 Jun 5 12:19 lib/
drwxr-xr-x  2 root wheel 1024 Jun 5 12:20 libexec/
drwxr-xr-x  3 root wheel 1024 Jun 5 12:20 man/
drwxr-xr-x  6 root wheel 1024 Jun 5 12:21 mysql-test/
drwxr-xr-x  2 root wheel 1024 Jun 5 13:42 run/
drwxr-xr-x  3 root wheel 1024 Jun 5 12:20 share/
drwxr-xr-x  7 root wheel 1024 Jun 5 12:21 sql-bench/
drwx------  4 root wheel 1024 Jun 5 13:37 var/

Note that at this point everything is owned by root — meaning the mysql account won’t be able to write to the databases under var/ nor be able to create the mysql UNIX socket in the run/ directory. Since we want to run the MySQL database under the mysql account, and not under the root account, we need to change the group association of /usr/local/mysql to the group mysql, and the ownership of /usr/local/mysql/run and /usr/local/mysql/var to the mysql account, as follows:

sudo chgrp -R mysql /usr/local/mysql
sudo chown -R mysql /usr/local/mysql/run /usr/local/mysql/var

The directory listing now looks like:

% ls -Fla /usr/local/mysql
total 26
drwxr-xr-x 13 root  mysql 1024 Jun 5 13:42 ./
drwxr-xr-x 11 root  wheel 1024 Jun 5 12:19 ../
drwxr-xr-x  2 root  mysql 1024 Jun 5 12:20 bin/
drwxr-xr-x  3 root  mysql 1024 Jun 5 12:19 include/
drwxr-xr-x  2 root  mysql 1024 Jun 5 12:19 info/
drwxr-xr-x  3 root  mysql 1024 Jun 5 12:19 lib/
drwxr-xr-x  2 root  mysql 1024 Jun 5 12:20 libexec/
drwxr-xr-x  3 root  mysql 1024 Jun 5 12:20 man/
drwxr-xr-x  6 root  mysql 1024 Jun 5 12:21 mysql-test/
drwxr-xr-x  2 mysql mysql 1024 Jun 5 13:42 run/
drwxr-xr-x  3 root  mysql 1024 Jun 5 12:20 share/
drwxr-xr-x  7 root  mysql 1024 Jun 5 12:21 sql-bench/
drwx------  4 mysql mysql 1024 Jun 5 13:37 var/

You can now start mysql and perform a few important tasks, like setting a mysql password to protect the database itself. Note that, while starting the database requires system root privileges, actions within the database itself do not require system root privileges, but database root privileges. It is somewhat confusing that MySQL uses the account name “root” for its all-powerful account, just as the system does, even though they are completely separate entities.

Starting mysql is accomplished with:

sudo /usr/local/mysql/bin/mysqld_safe --user=mysql &

Now you can run through some of the basic tests — but first, go ahead and secure the database by adding a password for the database “root” user, as follows:

/usr/local/mysql/bin/mysqladmin -u root password sniggle

Here “sniggle” is the password you are assigning to the database root account. In MySQL, a single user is associated with a username and a host. Most often on your development machine you will be connecting to the database locally, so the host will be “localhost”. However, if you are attempting to connect from a different machine, you will have to assign permissions based on both username and hostname. For more information on users and passwords within MySQL, read about MySQL’s grant tables, and the grant and revoke statements.

Conclusion

MySQL is a great database for Web applications and a great complement to a Mac OS X development environment. Install it on your machine and create applications in Perl, PHP, JSP, or whatever languages you like best. To administer a MySQL installation on Mac OS X, you can look to popular tools such as the Web-based phpMyAdmin from phpwizard.net, or MacSQL from Runtime Labs.

For information about starting MySQL on startup, see this article from macosxfaq.com.

Okay, so this was very much a case of fumbling around in the dark until stuff worked, lot’s of Googling and breaking stuff. The end result is a dev server on OS X that is running Textpattern with clean URLs and a copy of WordPress for good measure. These notes are primarily so I don’t forget how I did it, if they are useful to someone else, great! Be warned, though, I have no idea how secure this set up is and what flaws it has, so you follow these instructions at your own risk! Also, I am using OS 10.3.9 so I don’t know if this would work on Tiger.

Turn off Personal Web Sharing

OS X does, as you probably know, ship with Apache and it’s real easy to switch on and for a while I did use it. I am quite interested in learning a bit more about the whole serving up websites business, so first job is to do away with all the pre-installed Mac stuff.

Go to System Preferences > Sharing and make sure Personal Web Sharing is stopped.

Software

I started off with Mamp and that is probably good enough for a basic set up but I wanted to run Textpattern with clean URLs. Getting mod_rewrite to work on Mamp just wouldn’t happen for me. So after a bit of Googling I came up with these downloads in preparation for my mission… gulp!

• Complete MySQL
• Complete Apache2
• Complete PHP4
• CocoaMySQL
• Web Control (Scroll down the page a bit)

Terminal

You will need to have at hand Terminal in order to do some of the stuff. This is located in Applications > Utilities. This is the best bit actually because you get to feel like Neo for five minutes! Be careful though, I am told you can do some serious damage with Terminal.

Show hidden files

Having already had a play with Mamp, I noticed that I couldn’t see .htaccess files. Also when installing Complete MySQL there was another hidden file I needed to get to. Eventually I found a note on Apple’s developer site that describes how to show hidden files. It’s gonna make your Mac look at little messier than before but it’s kind of essential:

Open up Terminal and type in the following:

defaults write com.apple.Finder AppleShowAllFiles true

And that should be that.

Complete installs

The links to the three Complete packages are self explanatory. Each comes with a detailed Install document, follow them and you can’t go wrong, much.

The only problem I ran into was creating a .bash_profile document in the home directory. With hidden files now showing I could see that my home directory (the house with my name on it) had no .bash_profile in it, so I created one with TextEdit. Again, something to watch out for is TextEdit saving it with an extension e.g. .bash_profile.rdf. If this happens click on the file and press COMMAND + I which will bring up the File Info panel and you can simply delete the .rdf from the Name & Extensions panel

In truth this had little effect for me when trying to access mysql via Terminal, unless I used the complete path i.e. /Library/MySQL/bin/mysql. Given that I have no intention of using Terminal for accessing MySQL I didn’t worry about it and it has not had any impact on this setup thus far. Note: If anyone does know why I was getting a command not found error, I’d love to know.

One other note with these complete installs is the location they end up in. Obvious now but it caused me a bit of confusion, they are in the root library file and not the library file in you home directory. To find this spot open up your hard drive and look for the Library folder

phpMyAdmin versus CocoaMySQL

I had a bash at installing phpMyAdmin but to be honest they may as well have written the instructions in Wookie. I stumbled across CocoaMySQL after a bit of Googling, opened it up, it found the path to my MySQL server and within five minutes I had created a database as was running a local copy of Joshuaink. I thoroughly recommend it for the less technically minded.

Also worth noting is that which ever way you access MySQL, you can use your root account and the password you set when setting up MySQL for all your databases which is pretty damn convenient.

Httpd.config

Certainly if you are going to be experimenting, the httpd.config file will come into play. I started off with the Web Control app because it makes back ups, reverts easily back to the original file if you mess it up and it can check your syntax for you and if you aren’t feeling confident it’s a great way to start. It soon started to get a bit frustrating though because I couldn’t do a find search to locate bits of the document.

I ended up going back to TextEdit but found I could no longer save the file from that app (though I could from Web Control). I am not sure if this happens by default or whether Web Control did it when it first ran but it turned out that the conf directory, located at /Library/Apache2/conf was locked, so again clicking on the directory and COMMAND + I brings up the info and I changed the Ownership & Permissions details from Owner: system to Owner: [my username]. I also did the same to the httpd.conf file for good measure and made sure they were both set to Read & Write for owners.

Virtual hosts

Virtual hosts were one of the big things I wanted to get done and I found two tutorials. One over at Mezzoblue and one over at SitePoint (scroll down the tutorial a bit). In the end I opted for the SitePoint one because it was getting late and my head seemed to manage with it a little better, though the URLs it produces are no where near as cool as Dave’s. Again something to consider if you do use the SitePoint one, be careful with your naming conventions because it can impact how you use the web. For example I had a directory called joshuaink and where I used to just type joshuaink — as opposed to the full URL — into Firefox to reach my live site, I was now being taken to my localhost.

DirectoryIndex

It wasn’t until I opened up the WordPress admin that I noticed I was getting a directory listing and had to manually click on index.php to get to the login page. This seems to be something to do with the DirectoryIndex bit of httpd.conf. Initially I was dropping the .htaccess file that ships with Textpattern into each and every directory with an index.php as it’s starting point and it did solve the problem but that was getting a bit tiresome. Eventually I found out that there is something called DirectoryIndex in the httpd.conf file and having located it I changed it to this so that Apache recognises an index.php:

DirectoryIndex index.html index.htm index.php index.html.var

I really don’t know if that is correct but it seems to have solved the problem.

Deleting .htaccess files

My final problem was deleting those .htaccess files I had spread everywhere and OS X wouldn’t let me because it is a hidden file. To solve this I renamed it to .htaccess.txt and then I could delete it.

Conclusions

I have got a lot to learn about Apache but it was an interesting start and well worth the effort. With my iBook mostly offline, security is not a big deal for me. No doubt I will continue to fiddle until it breaks. If you have any tips or see something very wrong with the way I have setup, please do say.

FTP Only Accounts Under Mac OS X

The following howto describes how to set up ftp only accounts using Apple Mac’s built in ftp server (lukemftpd).

This outline requires you to use the terminal, NetInfo Manager and have admin privileges on the machine in question.

Warning: You can muck things up quite seriously using NetInfo Manager. At the very least make sure you have a recent, full back-up of the machine you’re planning to setup before going any further.

To create ftp only accounts we need to:

1. Create an ftp login shell
2. Restrict our prospective ftp user to their folder
3. Create the user account
4. Create a folder for the new user
5. Give the user a password

Create An FTP Login Shell

To create an ftp login shell we need to copy or link /sbin/nologin to /sbin/ftplogin. We’ll create a symbolic link from /sbin/nologin to /sbin/ftplogin. To do this:

1. Fire up Terminal
2. Type “sudo ln -s /sbin/nologin /sbin/ftplogin” (without the quotes)
3. Hit return
4. Type in your admin user’s password when prompted

Now we need to add the new “shell” to the list of shells available to the system. To do this we need to add “/sbin/ftplogin” to the list of shells given in the file found at /etc/shells. In Terminal:

1. Type “sudo pico /etc/shells”. This’ll open up the file “shells” in a simple text editor in Terminal
2. Hit return
3. Type in your admin user’s password if prompted
4. Add the string “/sbin/ftplogin” (without the quotes) on a new line at the end of the list of shells available. This’ll give you a final list similar to:

   /bin/bash
   /bin/csh
   /bin/sh
   /bin/tcsh
   /bin/zsh
   /sbin/ftplogin

5. Type ctl + “o”. That’s the letter “o” while holding down the control key
6. Hit return
7. Type ctl + “x” to eXit Pico

Restrict User To Their Folder

We’re setting this up now so that as soon as the user we’re creating gains access to our machine, they’re restricted to their log-in or root folder. All we have to do is create the file /etc/ftpchroot if it doesn’t exist and then add the prospective user’s username to the file.

1. In Terminal, type “cd /etc” (without the quotes. From here on in, I’ll assume you’re ignoring the quotes)
2. Check to see whether the file “ftpchroot” exists. If it doesn’t, type “sudo touch ./ftpchroot” and give you admin password if prompted for it

Now we need to add the username to the created file. Using pico:

1. In Terminal type “sudo pico ./ftpchroot”. This’ll open up the file “ftpchroot” in a simple text editor in Terminal
2. Type in your prospective ftp user’s username. Ours is “fred”. For safety, make the username all lowercase letters only – although we’ll let you have the underscore (“_”) too.
3. Type ctl + “o”. That’s the letter “o” while holding down the control key
4. Hit return
5. Type ctl + “x” to eXit Pico

Create User Account

We do this in NetInfo Manager. I’m going to talk you through doing this the long winded way – but once you’ve got one account set-up, I’d suggest you duplicate an existing account and modify it as appropriate.

1. Fire up NetInfo Manager
2. At the bottom of the pane, click the little lock symbol and supply your admin username and password to unlock NetInfo Manager
3. In the lefthand column, select “/”
4. In the middle column select “users”
5. Click the “New” icon at the top of the pane. This will create a new user called “new_directory”.

Now we need to modify this user account to give it the properties we’re after. Some of these properties will depend on your setup and how you want to administer your machine. We’ll use some reasonable settings but you may want to change these.

Before we go further, we do need to check what the next available user id (uid) is. To do this, click through your users in NetInfo Manager (ignoring the system users if you know what these are) making a note of the highest uid. In my case it’s 503. This means that my next user is going to be 504. Alternatively, start a new series for ftp users starting at 601.

Having done this, with the user “new_directory” selected in NetInfo Manager:

1. Select the “name” property in the bottom half of the pane. Double click on the Value “new_directory” to select it and type in your username. In our example our username, as added to the ftpchroot file is “fred” – so that’s what we’ll type here.
2. Create a new property by clicking in the “New” icon at the top of the pane. This will create a new property called “new_property”. Change the property value to “uid”. Now change its value “new_value” to the next available uid – or, if you’re starting a new series, 601.
3. Add a new property for the group id – “gid”. We’ll set this to “20″. i.e. Create the new property, select “new_property” and type “gid”. Select “new_value” and type “20″.
4. Follow this procedure to add:
   

   Property		Value(s)
   expire		0
   change		0
   shell		/sbin/ftplogin
   home		/Users/<username>

   Where the text “<username>” in the last property (“home”) is the username of the user you’re adding. In our example “fred”. So the value for the property “home” would be “/Users/fred”. This means the bottom of your NetInfo Manager pane should end up looking something like:

   Property		Value(s)
   home		/Users/fred
   shell		/sbin/ftplogin
   change		0
   expire		0
   gid		20
   uid		504
   name		fred

   2006-04-18: We’ve been contacted by Esben Sørensen and Antoine Durr over the weekend, both of whom make the observation that “realname” needs to be added to the properties listed here. i.e. we should end up with:

   Property		Value(s)
   home		/Users/fred
   shell		/sbin/ftplogin
   change		0
   expire		0
   gid		20
   uid		504
   name		fred
   realname		Fred

   So, add the “realname” property “else the account’s system preference pane will henceforth come up blank due to an incorrect/invalid realname” (Antoine Durr).

   Thanks to Esben and Antoine.

5. Make sure you remember the uid as you’ll need it in a sec.
6. Close NetInfo Manager saving and confirming the save as you go.

Create A User Folder

We need to create a user folder and then change its ownership (and permissions) to reflect those of the newly created user.

1. In Terminal, type “cd /Users”. Typing “ls” will give you a list of all the users on your machine
2. Type “mkdir <username>” where <username> is the new user’s username. We’ll be typing “mkdir fred”
3. Change the owner of this file by typing “sudo chown <uid>:20 ./<username>. Where <uid> is the uid for the user you added (and made a mental note of) and <username> is the username…. OK. You’ve got the idea. Oh. If your prompted for a password, give your admin password.
4. Change the permissions of this file so that we can all access it (if you know what you’re doing here, set the permissions as you see fit). “sudo chmod 777 ./<username>”

Now we’re on the home stretch.

Give The User A Password

The next step is to give the newly created user a password. To do this, in Terminal:

1. Type “sudo passwd <username>”. (So we’ll be typing “sudo passwd fred”).
2. Type in the new password at the prompt.
3. Retype it as prompted.

NAT?

If you’re behind a router or firewall which does Network Address Translation (NAT), there’s one more thing. Passive FTP requires the machine offering the FTP service to return its IP address and a port on which it’ll be listening. If you’re on a NATed network, it’s likely that the FTP server is going to return its internal IP number rather than the external address you’d prefer it to give. To get around this:

Create the file /etc/ftpd.conf

Add the line “advertise all <host>” where <host> is either the host name or external IP address for the FTP server.

Done

Restart the FTP server to ensure that all the caches are flushed and then see whether you can log-in via ftp as the new user. The easiest way of doing this is to turn FTP off and then on again in System Preferences -> Sharing.

Until the latest version of VirtualBox (1.4.1) released for Mac, there are still no support for the Host Interface networking option enabled yet. Moreover, you even could not see the NIC card got working on Mac OSX running in some Intel Machine (Jas 10.4.8) since it didn’t recognized properly with the built-in driver. So, is there anyway to get a simple networking between both OS? Sure it does.

FYI, file transfer in a Shared Folders option allow you to access files of your Mac OSX system from within the Windows XP guest system, much like ordinary shares on Windows networks would – except that shared folders do not need a networking setup. Sharing is accomplished using a special service on the host and a file system driver for the guest, both of which are – fortunately – provided by VirtualBox. In order to use this feature, the VirtualBox Guest Additions have to be installed in guest OS. Currently, shared Folders are limited to Windows XP, Windows 2000 and Linux 2.4 and 2.6 guests. To share a folder with a virtual machine in VirtualBox, you must specify the path of the folder to be shared on the host and chose a “share name” that the guest can use to access it.

Then, you can mount the shared folder from inside a VM the same way as you would mount an ordinary network share.
In Windows XP guest, use the following formula command:

net use x: \\vboxsvr\sharename

While vboxsvr is a fixed name, replace “x:“ with the drive letter that you want to use for the share, and sharename with the share name specified before.

To simplify this, I used to create a batch file which can executed manually to mount all of the 4 shared folder name (1 NTFS partition for Windows XP, 2 FAT32 partition for data & 1 HFS Mac OSX partition) specified before after the guest OS shows up. For example, named it with vboxsvr.bat and the picture below is the values:

You can also create a link for the batch file & move it to on a someplace you like for example in a quick launch panel.

To test the script, simply click the shortcut file until it processed completely. If it succeeded, the script will create new networking drives available assigned next to the drive letter defined before on the batch file.

However, I still don’t understand why it marked with Disconnected Network Drive label although files & folders on both OS is accessible as you may seen on ordinary full permission shared drives.