You like own storage? Install Owncloud!

Install ownCloud 

This section describes in detail how to install ownCloud from the source tar balls.


Download the latest version of ownCloud from https://owncloud.com/download/. It will arrive as a tar.bz2 file.

wget http://mirrors.owncloud.org/releases/owncloud-x.x.x.tar.bz2

Change into your webspace directory, confirm that there is no directory called “owncloud” that can be overwritten, and unpack the tar file.
tar -xjf path/to/downloaded/owncloud-x.x.x.tar.bz2

It will create the ownCloud application inside the subdirectory “owncloud”. To work properly, ownCloud needs to be inside your webspace. The default locations are on

openSUSE / SLES: /srv/www/htdocs/
Fedora / RHEL: /var/www/html/
Ubuntu / Debian: /var/www
The next step is to create the directory for ownCloud to store its files in. Change into your ownCloud directory and create a directory called data.

Once ownCloud is installed, you need to change some file permissions and ownerships to allow the web server to  access and update the ownCloud configuration files and store your data. To do this, change into your ownCloud directory and change the owner of some of the files to the apache user. The correct user varies by Linux distribution family. Here are some examples:

openSUSE / SLES:
Go to /srv/www/htdocs/owncloud (if that is your ownCloud directory)
Run:
chown -R wwwrun:www config data
chown wwwrun:www apps
chmod 750 apps config
chmod -R 770 data

Fedora / RHEL:
Go to /var/www/html/ (if that if your ownCloud directory)
Run:
chown -R apache:apache config data
chown apache:apache apps
chmod 750 apps config
chmod -R 770 data

Ubuntu / Debian:
Go to /var/www (if that is your ownCloud directory)
Run:
chown -R www-data:www-data config data
chown www-data:www-data apps
chmod 750 apps config
chmod -R 770 data

Open your web browser and navigate to your ownCloud instance. If you are installing ownCloud on the same machine as you will access the install wizard from, the url will be:http://localhost/ (or http://localhost/owncloud. For basic installs SQLite is easy to setup (ownCloud will do it for you). For larger installs you should use MySQL or PostgreSQL. Click on the Advanced options to show the configuration options. You may enter admin credentials and let ownCloud create its own database user, or enter a preconfigured user. At this point your install is finished . Happy uploading.

Big Files

The upload size is maybe restricted to 2 MB: As a default, PHP is configured for only 2 MB uploads. This is not entirely useful, so it is important to increase these variables to the sizes you want to support on your server. So edit your servers php.ini file and change this to your desired values. example:

upload_max_filesize = 500 MB
post_max_size = 600 MB

sftp into your AWS ec2 instance

This steps are required to SFTP into your AWS EC2 instance using FileZilla. Open Site Manager

• Add site
• Host: Ec2 elastic IP
• Port: 22 (will sort by default when you select next option)
• Protocol: SFTP
• Logon Type: Normal
• User: ec2-user

Open Preferences

• SFTP
• Add Key File select your secure key [.pem] from where you saved it

Make sure that the ec2-user has the correct permissions to do the actions you require.

Updating Drupal Core.

Updating Drupal Core always is a litte bit hardcore.
You need first delete most of the old code. Here is a step by step instruction for the update process.
 It is assumed that your custom modules and templates are in the sites/all folder.
Otherwise you get some more work to save the files. If you want to preserve your .htaccess robots.txt and favicon.ico save it before updating.
1. Backup of your Drupal instance.
2. Download the latest release of your current Drupal version.
3. Extract the [tar ball or zip] Drupal package.
4. Set your site on maintenance mode
5. Delete all the files & folders inside your original Drupal instance except for /sites folder and any custom files you added elsewhere.
6. Copy all the folders and files except /sites from inside the extracted Drupal package [tar ball or zip package] into your original Drupal instance.
7. If the update release includes changes to settings.php replace old settings.php in .../sites/default/ with the new one, and edit site-specific entries (eg database name, user, and password)
8. If you modified files such as .htaccess or robots.txt re-apply those changes to the new files.
9. Login to your site as administrator or as user no 1
10. Run update.php by navigating to http://...yoursitename/update.php
11. Follow the process to update your Drupal instance 12. Disable maintenance mode

Centos - Installing graphical X Window System (Boot Options, startx from command line)

Installing GUI

Installing the Graphical Window System (X.org-X11) and the Default Desktop Environment on CentOS 6

Performing the default "Minimal" install of CentOS 6 does not install the graphical subsystem (the X.org server) and the desktop environment (e.g. GNOME or KDE). Such OS install is nice for building an optimal system from scratch, setting up a headless server (no monitor, keyboard and mouse) and other purposes; but for one reason or another, you may still require a graphical user interface (GUI). This tutorial will show you how to install and start the graphical window system and the desktop environment of your choice.

To achieve the task, you will need to install the following package groups (groups of packages combined for a common purpose): "X Window System", "Desktop", "Fonts" and "General Purpose Desktop" (last two are optional). This will install about 500 additional packages on your system (~250MB download, or you may use the available OS installation DVD to retrieve packages).

Code:

yum -y groupinstall "X Window System" "Desktop" "Fonts" "General Purpose Desktop"

(Please enter this as is - package group names as well as package names are case sensitive).

Previous versions of RHEL and its derivatives provided a package group called "GNOME Desktop Environment", that was sufficient for a general purpose GNOME desktop. Currently, package group "Desktop" installs all critical components of GNOME, including gdm (the GNOME Display Manager), plus a few additional packages; enough to provide a minimalist GNOME desktop with mouse support, a graphical file manager, copy/paste functionality and the luxurious GNOME Terminal emulator - maybe just what you need. Thus, installing the "General Purpose Desktop" package group is optional, but will help you mimic the system you would probably get if you where to include the default graphical desktop during OS install. Alternatively, you can chose a single package group "KDE Desktop", for a general purpose KDE Software Compilation.

It is generally recommended to install the "Fonts" package group to improve usability of the GUI, no matter what desktop environment you choose to install.

You may view the complete list of available package groups by issuing:

Code:

yum grouplist

You may review the contents of each package group by entering:

Code:

yum groupinfo "Name of the Package Group"

Enabling booting into GUI - start GUI from command line

To boot directly into GUI, you will need to manually change the runlevel of the system from 3 (full multiuser environment with networking) to 5 (the same as mode 3 + X11), by changing the line "id:3:initdefault:" to "id:5:initdefault:" in /etc/inittab file. Or you can manually start X.org from console, by entering "startx" (without quotes).

Upon installation and subsequent reboot, you will be presented with the "Setup Agent" interface (even if you choose to stay in runlevel 3, you will see the text user interface of this tool - hence, the options provided will be different from the graphical variant). This is due to package "firstboot" being automatically installed by the "X Window System" package group and can be a handy way to setup a freshly installed system. All steps in "Setup Agent" are optional, so you can just skim through them, skipping any. Though, creating a new normal user on a freshly installed system is done best through this graphical tool, as it helps automatically create the new user and associate it with groups (such as the "video" group) appropriate for everyday use in a GUI environment . 

If you have installed the X Window System but are not seeing a graphical desktop environment once you log into your Red Hat Enterprise Linux system, you can start the X Window System graphical interface using the command startx.

Once you enter this command and press Enter, the graphical desktop environment is displayed.

Note, however, that this is just a one-time fix and does not change the log in process for future log ins.

To set up your system so that you can log in at a graphical login screen, you must edit one file,/etc/inittab, by changing just one number in the runlevel section. When you are finished, reboot the computer. The next time you log in, you are presented with a graphical login prompt.

Open a shell prompt. If you are in your user account, become root by typing the su command.

Now, type gedit /etc/inittab to edit the file with gedit. The file /etc/inittab opens. Within the first screen, a section of the file which looks like the following appears:

# Default runlevel. The runlevels used by RHS are: 
#   0 - halt (Do NOT set initdefault to this) 
#   1 - Single user mode 
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking) 
#   3 - Full multiuser mode 
#   4 - unused 
#   5 - X11 
#   6 - reboot (Do NOT set initdefault to this) 
#  id:3:initdefault:

To change from a console to a graphical login, you should change the number in the lineid:3:initdefault: from a 3 to a 5.

Warning

Change only the number of the default runlevel from 3 to 5.

Your changed line should look like the following:

  id:5:initdefault: 

When you are satisfied with your change, save and exit the file using the Ctrl-Q keys. A window appears and asks if you would like to save the changes. Click Save.

Install and run NTP on Centos

Having an accurate clock on your system is usually important. It ensures the time stamps in emails sent from the machine are correct, and it is especially helpful when you need to look at the logs from a particular time of day.

Network time protocol

That's where the network time protocol (NTP) comes in. NTP lets you automatically sync your system time with a remote server. Setting up an NTP server to regularly adjust your machine's clock is pretty easy by default. It's also possible to make it a bit more complicated if you need your clock accurate down to the millisecond instead of just to the second.

Install

The first thing to do is install the NTP server.
Grab the package by running:
sudo yum install ntp

Once it's installed you can ensure the service will run at boot time by running:
sudo /sbin/chkconfig ntpd on

Start the service
To make sure the NTP service starts after installing it, run:
sudo /etc/init.d/ntpd start

As is usual for Linux services, you can stop or restart the NTP service by running the above command with "stop" or "restart" sent as the argument instead of "start".
Your system time is now served by NTP.

Fine Tuning

The ntp.conf file.The NTP configuration file can be found at:

/etc/ntp.conf

There are a few settings that can be changed in there, but for most people the only settings of interest would be any "server" entries.
The default for CentOS looks like:

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.centos.pool.ntp.org
server 1.centos.pool.ntp.org
server 2.centos.pool.ntp.org

With more than one "server" entry your NTP server will query all servers and only select a time that a majority of the polled servers will agree on. This basically means that with three or more servers your clock will be more accurate than if it just uses one. If you add the "iburst" option after the server address it can speed up the NTP time sync by a bit. It's usually a good idea to use it, but not essential.

Further Reading:
ntp.org

Encoding video with encoding.com

Encoding can be a hard job. Why not outsource it? Encoding.com takes your video, encodes it and sends it back to you. For small consumers and testing purposes there is a free package available. 

There are different methods to send your video. 

Desktop Application — An Adobe Air application available on both Windows and OSX platforms enables complete upload and management of your encoding projects directly from your desktop. 

Web Interface — The client interface has a section entitled Add Media. This tool will allow you to quickly and easily encode individual videos in to one or more formats through your browser (via upload from hard drive, FTP, SFTP, S3, CloudFiles).

Watch Folder — Also in the client interface, the Watch Folder allows you to specify an FTP/SFTP/S3/CloudFiles directory for encoding.com to "watch" at any frequency for new videos. After each watch interval all new videos added to this folder will be processed using the encoding setting you selected. You can have as many watch folders as you like, making it possible to encode a large video library with little or no setup or integration work. Please see our collection of articles about the Watch Folder for more details. 

XML API is the most flexible method. Custom file naming, multiple output formats and real time encoding status updates are important features available via our API. 

Uploading the file via web interface

Drag and drop uploading via the Desktop Application

After uploading your video you can start encoding.
Basic encoding settings are Audio Codec, Bitrate, Destination Locations, File Size, Framerate, Notifications, Output Type, Source Video Locations and Thumbnails.

Choose your encoding task

Task overview

When the task is finished encoding.com sends the file to the  Network of choice: S3, CloudFiles, FTP, or most commonly, directly to your Content Delivery ce (Akamai, EdgeCast, Highwinds, CloudFront, Level 3, Limelight, CDNetworks, NetDNA, etc.) or you can download it manually.

Possible Third Party integrations are:

Amazon S3 Cloud Storage, CMS Systems (Drupal, etc.), Content Delivery Networks (CDN), Flash Players, Rackspace Cloud Files and Video Platforms can be linked to encoding.com.

Link to encoding.com

Wowza and Red5 same server

Sometimes it is useful to have  Wowza and Red5 on the same server. As both use the same ports, you have to change them in one applicattion.

Wowza default ports:

The following ports are used by default by Wowza Media Server 3 for streaming. You will need to open up these ports on your firewall to enable streaming. 

• TCP 1935: RTMP (all variants), RTSP, Smooth and Cupertino Streaming
• UDP 6970-9999: RTP UDP Streaming
• TCP 8084-8085: JMX/JConsole Monitoring and Administration
• TCP 8086: HTTP Administration

Red5 default ports:

• RTMP: 1935
• RTMPT: 8088
• HTTP servlet engine port: 5080
• Debug proxy port: 1936

Here is how to do change ports in Red5:

The first file we need to modify is the server properties file located in the conf directory:
red5/conf/red5.properties

• Locate the http.port key and change it to 80 (or whatever you want)instead of 5080
• Locate the proxy.source_port an change it to 1937 (or whatever you need)
• Do not change the rtmpt.port entry, it should be 8088
• Save and close the file
• If you have any webapps do not forget to modify the ports in the red5/webapps/yourapp/config.xml
• restart Red5