• This guide will show you how to configure an IMAP account in Outlook 2011 for Mac with Exchange 2010

• Applicable to

  All SherWeb hosted Exchange 2010 accounts.

• Prerequisite

  • a SherWeb hosted Exchange 2010 account
  • an Outlook 2011 client

• How to

  1. Open Outlook 2011 for Mac.
  2. Click on E-mail Account.
  3. Enter your emal address in the E-mail address field, your password in the Password field, domain\SAM_account_name in the User name field. Then, choose IMAP in the Type dropdown menu, enter webmail.sherweb2010.com in the Incoming server field, check the box Use SSL to connect, enter smtp.sherweb2010.com in the Outgoing server field, check the boxes Override default port and Use SSL to connect, change the port to 587 for the Outgoing server. Finally, click on Add Account.
  4. Click on More Options.
  5. Choose Use Incoming Server Info in the Authentication drop down menu and then click on OK.
  6. Click on Advanced for more optional settings.

  If you need further assistance, please do not hesitate to contact us.
  

• Keywords

  Outlook 2011, Mac, Exchange, Share F

REFERENCES
http://support.sherweb.com/Faqs/Show/how-to-configure-an-imap-account-in-outlook-2011-for-mac-exchange-2010

I had an issue with free disk space (or, more appropriately, a lack there of) on my server a while back. After some investigation, I discovered that my MySQL databases had ballooned in size to nearly 10 GB. Actually, figuring out that the /var/lib/mysql directory was taking up so much space wasn't that hard, but understanding why and what to do about it took a while (yes, I'm sometimes slow about such things).

It turns out I had two issues. The first is that MySQL configuration, by default, maintains binary logs. These logs "contain all statements that update data or potentially could have updated it (for example, a DELETE which matched no rows). Statements are stored in the form of 'events' that describe the modifications. The binary log also contains information about how long each statement took that updated data."[1] This is fine and all, but (again by default) these log files are never deleted. There is a (configurable) max file size for each log, but MySQL simply rolls over to a new log when it's reached. Additionally, MySQL rolls over to a new log file on every (re)start. After a few months of operation, it's easy to see how this can take up a lot of space, and my server had been running for nearly four years.

Complicating matters somewhat was the fact that the default name of the binary logs changed at some point (and, according to the current docs, now appears to have changed back. As a result, I have several gigabytes worth of logs using the old naming convention, as well as several gigabytes worth of logs using the newer convention. Yay.

Like I said, recognizing that MySQL was taking up a lot of space is not hard, but I'm paranoid about my data and didn't want to risk losing anything. So, I kept putting it off until I was literally running out of space on a near daily basis. At that point I began doing research and figured out all of the above information. I also found a quick an easy way to fix the problem.

Note: This is meant for a standalone MySQL server. I'm not sure how it may affect replication, so please do not follow these instructions on a replicated server without additional research.

First of all, the binary logs typically reside in /var/lib/mysql/. You can check to see how much space they're currently taking up with this one-liner: du -hcs /var/lib/mysql/*bin.* | tail -n 1. If it's more than a few hundred megabytes, you may want to continue on.

Next, check to see if you were affected by the name switch like I was. This is unlikely unless you've been running the server for at least a year or so, but it definitely doesn't hurt to check. Look at all *bin.* files. If they're all named the same, such as mysqld-bin.000001, then you're fine. If you see some with a different name, such as both mysqld-bin.000001 and hostname-bin.000001, then you have an outdated set of logs doing nothing but taking up space. Look at the timestamps of the .index file for each set. One should be very recent (such as today), the other not. Once you've identified the older set, go ahead and delete all of them; they're no longer being used.

Finally, for the current set, login to MySQL as an admin user (eg., mysql -u root -p). You'll want to run the following two commands:
mysql> FLUSH LOGS;
mysql> RESET MASTER;

That's it. Depending on the size and number of your logs, those two commands may take a while to run, but the end result is that any unsaved transactions will be flushed to the database, all older logs will be dropped, and the log index will be reset to 1. In my case, these two steps dropped my from 9.6 GB down to about 5 MB. Good stuff.

Of course, this is simply a workaround to the problem, not a proper solution. What I'd really like to do is either automate this process so that I don't have to worry about the logs getting out of control, or even better configure MySQL to automatically flush its own logs after some period of time or it reaches a certain total file size. I haven't found any way to do this just yet, though I admittedly haven't looked too hard. I'd appreciate any recommendations, though.

[1] http://dev.mysql.com/doc/refman/5.0/en/binary-log.html



REFERENCES
http://legroom.net/2008/06/29/flush-and-reset-mysql-binary-logs

Q. I get a large amount of bin files in the MySQL data directory called "server-bin.n" or mysql-bin.00000n, where n is a number that increments. What is MySQL Binary Log? How do I stop these files being created?


A. Usually /var/lib/mysql stores the binary log files. The binary log contains all statements that update data or potentially could have updated it. For example, a DELETE or UPDATE which matched no rows. Statements are stored in the form of events that describe the modifications. The binary log also contains information about how long each statement took that updated data.

The purpose of MySQL Binary Log

The binary log has two important purposes:

• Data Recovery : It may be used for data recovery operations. After a backup file has been restored, the events in the binary log that were recorded after the backup was made are re-executed. These events bring databases up to date from the point of the backup.
• High availability / replication : The binary log is used on master replication servers as a record of the statements to be sent to slave servers. The master server sends the events contained in its binary log to its slaves, which execute those events to make the same data changes that were made on the master.

Disable MySQL binlogging

If you are not replicating, you can disable binlogging by changing your my.ini or my.cnf file. Open your my.ini or /etc/my.cnf (/etc/mysql/my.cnf), enter:
# vi /etc/my.cnf

Find a line that reads "log_bin" and remove or comment it as follows:

#log_bin                        = /var/log/mysql/mysql-bin.log

You also need to remove or comment following lines:

#expire_logs_days        = 10
#max_binlog_size         = 100M

Close and save the file. Finally, restart mysql server:
# service mysql restart

 

Purge Master Logs

If you ARE replicating, then you need to periodically RESET MASTER or PURGE MASTER LOGS to clear out the old logs as those files are necessary for the proper operation of replication. Use following command to purge master logs:

$ mysql -u root -p 'MyPassword' -e "PURGE BINARY LOGS TO 'mysql-bin.03';"

OR

$ mysql -u root -p 'MyPassword' -e "PURGE BINARY LOGS BEFORE '2008-12-15 10:06:06';"

Suggested readings:

MySQL Manual - The binary logs


REFERENCES
http://www.cyberciti.biz/faq/what-is-mysql-binary-log/

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "!(android|blackberry|googlebot-mobile|iemobile|ipad|iphone|ipod|opera mobile|palmos|webos)" [NC]
RewriteRule ^$ http://www.example.com/ [L,R=302]
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "android|blackberry|googlebot-mobile|iemobile|ipad|iphone|ipod|opera mobile|palmos|webos" [NC]
RewriteRule ^$ http://m.example.com/ [L,R=302]
</IfModule>

REFERENCES
http://www.howtoforge.com/apache2-how-to-redirect-users-to-mobile-or-normal-web-site-based-on-device-using-mod_rewrite

Server Training - Web Server

SELinux with Apache Security with Apache is an important topic, of which SELinux is a part. However, the frustration that results in trying to manage SELinux and how it relates to an Apache Web Server is huge. Most of the time, administrators bail and shut down SELinux because they do not have the time to correctly configure the system. SELinux can be a key to good security for the Apache daemon. This tutorial with help you develop several skills that will provide some level of SELinux management for the Apache Web Server. View Processes protected by SELinuxYou may view processes which are restricted by SELinux with ps. While your Apache Web Server is running you can view the processes under management. Remember that by default Apache will start 8 web servers when it is initialized so that is why you see this number of processes running. The ps command had to be completely rewritten to provide these SELinux attributes. # ps -ZC httpd LABEL PID TTY TIME CMD root:system_r:httpd_t 11759 ? 00:00:00 httpd root:system_r:httpd_t 15899 ? 00:00:00 httpd root:system_r:httpd_t 15900 ? 00:00:00 httpd root:system_r:httpd_t 15901 ? 00:00:00 httpd root:system_r:httpd_t 15902 ? 00:00:00 httpd root:system_r:httpd_t 15903 ? 00:00:00 httpd root:system_r:httpd_t 15918 ? 00:00:00 httpd root:system_r:httpd_t 15919 ? 00:00:00 httpd root:system_r:httpd_t 15920 ? 00:00:00 httpd If you wanted to view the entire list of processes currently protected with SELinux you would use this command: # ps -eZ LABEL PID TTY TIME CMD system_u:system_r:init_t 1 ? 00:00:00 init system_u:system_r:kernel_t 2 ? 00:00:00 migration/0 system_u:system_r:kernel_t 3 ? 00:00:00 ksoftirqd/0 system_u:system_r:kernel_t 4 ? 00:00:00 watchdog/0 system_u:system_r:kernel_t 5 ? 00:00:00 events/0 system_u:system_r:kernel_t 6 ? 00:00:00 khelper system_u:system_r:kernel_t 7 ? 00:00:00 kthread system_u:system_r:kernel_t 10 ? 00:00:00 kblockd/0 system_u:system_r:kernel_t 11 ? 00:00:00 kacpid ---cut--- SELinux sees everything as an object. Access to objects are controlled by security elements stored in the inode, which now has extended fields. The security elements combined create a security context which consists of five elements. user The role is used to indicate the user of the context. If a user logs in as root they will have a user value of root. If they log in as a regular user, like tom, they will have the value of user_u. Users who su to root will continue to have the value of user_u. Processes also have a value, system_u. role This is used to define the role of the user. Files have a role of object_r and processes have a role of system_r. Users, like processes have the role of system_r. type Types are used to create a type enforcement which determines which process types can have access to which file types. sensitivity This is a security feature used by government agencies. category This provides a way to block access to categories of people including root. user: role: type: sensitivity: category If you view the settings for the index.html file in /var/www/html you will see these attributes listed. # ls -Z -rw-r--r-- root root root:object_r:httpd_sys_content_t index.html user: root: role: object_r: type: httpd_sys_content_t sensitivity: category It is important to note that the type: httpd_sys_content_t is required in order to view a SELinux object such as index.html. This type serves up content whereas if you wanted to use a cgi program or any other active page you will need a different type. Listed below are various types and also how to manage those types so they work. If you are going to use the apache web server you will need to know how to adjust the SELinux for that daemon. The first step in this process is to evaluate the booleans that are set for httpd in SELinux. Here is a list of the types that are available for the Apache Web Server. # getsebool -a | grep httpd allow_httpd_anon_write --> off allow_httpd_mod_auth_pam --> off allow_httpd_sys_script_anon_write --> off httpd_builtin_scripting --> on httpd_can_network_connect --> off httpd_can_network_connect_db --> off httpd_can_network_relay --> off httpd_disable_trans --> off httpd_enable_cgi --> on httpd_enable_ftp_server --> off httpd_enable_homedirs --> on httpd_rotatelogs_disable_trans --> off httpd_ssi_exec --> off httpd_suexec_disable_trans --> off httpd_tty_comm --> off httpd_unified --> on Here is a brief description of several major types. httpd_sys_content_t Set files with httpd_sys_content_t for content which is available from all httpd scripts and the daemon. httpd_sys_script_exec_t Set cgi scripts with httpd_sys_script_exec_t to allow them to run with access to all sys types. httpd_sys_script_ro_t Set files with httpd_sys_script_ro_t if you want httpd_sys_script_exec_t scripts to read the data, and disallow other sys scripts from access. httpd_sys_script_rw_t Set files with httpd_sys_script_rw_t if you want httpd_sys_script_exec_t scripts to read/write the data, and disallow other non sys scripts from access. httpd_sys_script_ra_t Set files with httpd_sys_script_ra_t if you want httpd_sys_script_exec_t scripts to read/append to the file, and disallow other non sys scripts from access. httpd_unconfined_script_exec_t Set cgi scripts with httpd_unconfined_script_exec_t to allow them to run without any SELinux pro- tection. This should only be used for a very complex httpd scripts, after exhausting all other options. It is better to use this script rather than turning off SELinux protection for httpd. SELinux policy is customizable based on least access required. So by default SElinux prevents certain http scripts from working. httpd policy is extremely flexible and has several booleans that allow you to manipulate the policy and run httpd with the tightest access possible. Here is the process for changed the status of these booleans for the Apache Web Server. Enable cgi If you wanted to enable the server to run cgi scripts you will need to change the boolean to allow this type. And...this is important...you will need to alter your cgi scripts so that their type is this type for cgi. # setsebool -P httpd_enable_cgi 1 Now that you have enabled cgi you will need to change the type for your cgi applications. Type Enforcement is the primary method of security for the targeted policy. The Type can be changed using the chcon command. However, the chcon command can only change to a Type that is defined by the policy. # ls -Z -rw-r--r-- root root root:object_r:httpd_sys_content_t myprogram.cgi In this example the cgi program will not be able to execute as it is a content type not the cgi type. # chcon -t httpd_sys_script_exec_t myprogram.cgi # ls -Z -rw-r--r-- root root root:object_r:httpd_sys_script_exec_t myprogram.cgi Now the cgi should be able to execute. Enable User home Directories and Change Context You may want to allow users to show web pages from their home directory. # setsebool -P httpd_enable_homedirs 1 # chcon -R -t httpd_sys_content_t ~user/public_html Enable Access to Terminal httpd may need to prompt for a password on a certificate file # setsebool -P httpd_tty_comm 1 Disable File Control Contexts # setsebool -P httpd_unified 0 Disable PHP You will need to manage the PHP settings for SELinux in order to run PHP. # setsebool -P httpd_builtin_scripting 0 Enable Network Connections from httpd Disabled to prevent hackers from attacking other machines from httpd. # setsebool -P httpd_can_network_connect 1 Disable suexec Transition # setsebool -P httpd_suexec_disable_trans 1 Disable Protection for httpd Daemon # setsebool -P httpd_disable_trans 1 # service httpd restart Changing a http Port You may want to change a port number for http. You cannot do this without editing the configuration for SELinux. # semanage port -l | grep http http_cache_port_t tcp 3128, 8080, 8118 http_cache_port_t udp 3130 http_port_t tcp 80, 443, 488, 8008, 8009, 8443 pegasus_http_port_t tcp 5988 pegasus_https_port_t tcp 5989 Change httpd to port 81 in the httpd.conf file. Listen 81 Now restart, and you will see that it will fail to restart. Check /var/log/messages for output. Dec 10 08:03:46 cent2 setroubleshoot: SELinux is preventing the /usr/sbin/httpd (httpd_t) from binding to port 81. For complete SELinux messages. run sealert -l 9d1872a0-da1f-48b3-b7bc-4ed7094387e5 In order to fix this you will need to use the semanage command to add port 81 to the ports allowed by SELinux. # semanage port -a -t http_port_t -p tcp 81 Restart httpd and you will find that it works. Now verify that port 81 was added to the default allowed ports. # semanage port -l | grep http http_cache_port_t tcp 3128, 8080, 8118 http_cache_port_t udp 3130 http_port_t tcp 81, 80, 443, 488, 8008, 8009, 8443 pegasus_http_port_t tcp 5988 pegasus_https_port_t tcp 5989 Managing Context Problems A common problem is when you create HTML pages in a user directory with the context of the user and then copy them to the http directories to be used as web pages. Here is an example. Mike build an index.html page to be moved into the root directory for httpd. The file is created in the user's home directory and as you can see it will have this context: # ls -Z index.html -rw-rw-r-- mike mike root:object_r:user_home_t index.html That file is copied into /var/www/html as the main index page but still has the same context, at least in some scenarios if the user has rights in the directory. # ls -Z /var/www/html -rw-r--r-- root root root:object_r:httpd_sys_content_t index.html Changing the Type Type Enforcement is the primary method of security for the targeted policy. The Type can be changed using the chcon command. However, the chcon command can only change to a Type that is defined by the policy. # ls -Z -rw-r--r-- root root root:object_r:httpd_sys_content_t index.html # chcon -t tmp_t index.html # ls -Z -rw-r--r-- root root root:object_r:tmp_t index.html You may also want to use a reference file to change the Type using the chcon command. The idea is to locate a file with the correct settings and then use it as a reference to correct another file. The example shows that the index.html file is incorrect but that the test.htm file can be used as a reference to fix the index.html file. # ls -Z -rw-r--r-- root root root:object_r:tmp_t index.html -rw-r--r-- root root root:object_r:httpd_sys_content_t test.htm # chcon --reference test.htm index.html # ls -Z -rw-r--r-- root root root:object_r:httpd_sys_content_t index.html -rw-r--r-- root root root:object_r:httpd_sys_content_t test.htm Another way to correct the problem is to use restorecon. This command can be used to bring all files in a directory back to the required Type. In this example restorecon repairs the index.html file that would not work correctly. Be sure to put a “/*” at the end of the directory you want to fix. # ls -Z -rw-r--r-- root root root:object_r:tmp_t index.html -rw-r--r-- root root root:object_r:httpd_sys_content_t test.htm # restorecon /var/www/html/* # ls -Z -rw-r--r-- root root system_u:object_r:httpd_sys_content_t index.html -rw-r--r-- root root root:object_r:httpd_sys_content_t test.htm REFERENCES http://beginlinux.com/server_training/web-server/976-apache-and-selinux