Thank you for looking through our FAQ. You might also be interested in the FAQ maintained by UF Web Services. If you have any suggestions for improving this site, please see our contact page and use the contact form.
A) Once your website has been created you will recieve communication that provides you with your new username and initial password. Using your new credentials you can login to glint.osg.ufl.edu with one of the secure shell protocols: ssh/scp/sftp Because glint is on private IP, you will need to be logged in to the UF VPN or be on a host in the UF network. If you're unfamiliar with these we recommend looking into WinSCP as it seems to work well for other customers. If you're on a Mac or Linux ssh/scp utilities are available on the command line.
You'll also need to ssh for shell access to glint in order to change your initial password. If you're on Windows try PuTTY ssh client. Again, Mac and Linux users have ssh on the command line. Once you have a shell on glint see the "How do I change my glint password" item in this FAQ.
Q) Why doesn't E-mail from my webapp/website CGI get sent properly or at all?
A) This is one of the most common questions we get and it has to do with our CGI environment and how smtp.ufl.edu handles email. There's a short answer to this problem and a longer background story, so here goes...
Short answer - you need to have your mail function specify the envelope sender address (not the header from address) to the mail submission program (sendmail). When you do this be sure to use one of (1) a valid gatorlink address or (2) an address outside of the @ufl.edu namespace. If you would be so kind as to use a deliverable address we'd appreciate it because it will prevent our postmaster from receiving bounces.
To specify the envelope sender address with php's mail() function use the "additional_parameters" argument to mail(). See example #3 at http://php.net/manual/en/function.mail.php
Long story - In our web hosting environment when you submit mail by default your code will do so as whatever system user is executing the CGI code. For most users this will be the cnswww- prefixed username we've given you to manage your website- let's say "cnswww-you". So by default sendmail gets a messages submitted by cnswww-you and adds that id to the message's envelope with the assumed @ufl.edu domain. Sendmail then hands the message off to smtp.ufl.edu which sees the envelope sender address as firstname.lastname@example.org. To cut down on fraudulent email passing through smtp.ufl.edu it is configured to verify any @ufl.edu addresses that are attempting to send messages. So when smtp.ufl.edu tries to lookup cnswww-you more than likely that's not a valid Gatorlink mailbox, so smtp.ufl.edu will reject the message.
So to prevent this rejection from occuring you can manually set the envelope sender addess (using the -f option to sendmail) to be either a valid Gatorlink mail address or some address that is deliverable on another system outside of @ufl.edu.
If you're not sure what is meant by the "envelope sender address" or how that differs from a message's "header from address" see the "Envelopes and Bodies" section on http://www.sendmail.org/resources
A) There are two types of accounts that you may use to login to glint. Here are the two most common cases:
Most of our Apache hosting customers will have a "service account" probably with a 'cnswww-' prefix, or at least a '-' character somewhere in the username. For these users it's important to understand that your password is stored in Kerberos, so you'll need to use the 'kpasswd' utility to update your password. Here's an example of using that utility:
$ kpasswd <username>
Password for <username>@UFL.EDU:
Enter new password:
Enter it again:
kpasswd: Cannot contact any KDC for requested realm changing password
You can ignore that last line - the password change will succeed even with that message.
Customers may notice PHP sessions do not work as expected or may see a PHP warning "Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/session)".
A) Since CNS apache web hosting is configured in a cluster, the default method of storing PHP session info to local disk is not advisable. PHP sessions should be stored in the database (preferred) or stored in a non-web-accessible location such as
This is accomplished by appending "-d session.save_path=<path>" to the end of the "exec" line in
The full line would look similar to:
exec $PHP_CGI -d session.save_path=/h/<cnswww-user>/<website>/sessions/
Note: sites configured with fastcgi will require CNS to modify the configuration to change the session save path.
Customers often want to increase the size limit on WordPress file uploads from the default 2MB.
A) Since WordPress is a PHP application, the easiest place to make the change is in the command line that starts PHP.
This is accomplished by appending (for example) "-d upload_max_filesize=20M -d post_max_size=20M -d memory_limit=64M" to the end of the "exec" line in
The full line would look similar to:
exec $PHP_CGI -d upload_max_filesize=20M -d post_max_size=20M -d memory_limit=64M
A) While customers cannot edit the server-wide php.ini file, most PHP configuration options can be specified on the command line. This is accomplished by appending multiple "-d <option>" to the end of the "exec" line in
Common options include the file upload size or maximum post size. Increasing these settings to 24 MB and 12 MB would look similar to:
exec $PHP_CGI -d upload_max_filesize=24M -d post_max_size=12M
Note: sites configured with fastcgi will require CNS to modify php options such as upload_max_filesize.
A) When uploading files via glint it is likely that the files will be given the permission of "world readable". If you are uploading files that are executed in the cgi environment (e.g. PHP, Perl, Python, and many content management systems such as Wordpress, Drupal, etc.), you likely want to restrict permissions so only your hosting account can read the files. This is especially true of site configuration files that hold database credentials.
The following directory listing shows a world readable file (in Unix terminology, "other" users have "read" permission as indicated by the "r" in the third / rightmost group of columns):
$ ls -al total 8 drwxr-x--- 2 cnswww-user cnswww-user 80 Jul 17 15:29 . drwxr-xr-x 5 cnswww-user cnswww-user 1024 Jul 16 15:26 .. -rw-r--r-- 1 cnswww-user cnswww-user 0 Jul 17 15:29 myfile
To make a file so it is only accessible by the owner:
$ chmod 600 myfile
which in this case is the same as removing "read" permission from "group" and "other":
$ chmod go-r myfile
After the change, the directory now looks like the following:
$ ls -al total 8 drwxr-x--- 2 cnswww-user cnswww-user 80 Jul 17 15:29 . drwxr-xr-x 5 cnswww-user cnswww-user 1024 Jul 16 15:26 .. -rw------- 1 cnswww-user cnswww-user 0 Jul 17 15:29 myfile
It is also a best practice to keep your site configuration files outside of the htdocs / document root so they cannot be accidentally served up to the web. Some Content Management Systems allow this.
NOTE: Do not do a global permission change to 600 on all files under your htdocs. Statically served content (e.g. in most cases .html, images and CSS files) must still be readable by the apache user.
A) If the perl library is included as part of the RHEL5 platform, you may simply contact us via Remedy ticket and ask us to configure the package for our web clusters. If the package could conflict with the default perl, or might otherwise be non-standard, you may wish to install a local perl or perl libraries in your document root.
A) Edit the php.cgi file in your document root:
#!/bin/bash PHP_CGI=/usr/bin/php-cgi exec $PHP_CGI
#!/bin/bash PHP_CGI=/usr/bin/php-cgi exec $PHP_CGI -d error_log=/h/cnswww-user/error.txt -d display_errors=On -d error_reporting=2147483647
(change user to your username).