Home | News | Reports | Articles | Softwares | Websites | Books | Archives  | Sitemap
What's new in Zend Framework V1.5

Level: Intermediate

Katie Horn (K4@engineering.phenomenauts.com), Developer, Freelance

15 Apr 2008

The popular open source Zend Framework just got some slick enhancements. Learn what's new in V1.5 and how upgrades, including Zend_Form, Zend_Layout, and Zend_View, enhanced support for GData Web services, and improved Ajax support can help PHP developers easily roll out cutting-edge Web applications.

A software framework is a collection of code libraries designed to take care of all the basics required in an application in a standardized way so application developers can spend their time developing, instead of constantly having to reinvent the wheel. There are dozens of open source PHP development frameworks out there to choose from, and of all those available, the Zend Framework is perhaps the most popular.

Zend stands out by putting a huge emphasis on best practices, which appeals to those of you who value sustainability. Zend also makes a point of constructing the framework in a remarkably modular fashion: Most of the individual Zend Framework components can be pulled completely out and used on their own, which appeals to developers who only need a fraction of the available libraries. Zend's flexibility, combined with the solid standardization that comes with emphasizing best practices, makes it a practical framework for a broad spectrum of purposes.

The already-powerful Zend Framework has gained several entirely new components and component enhancements in V1.5. The upgrades make developing complicated PHP applications even easier and more maintainable down the road due to the implementation of standards in things like form-validation routines and even front-end layout creation. Let's start by taking a look at the Zend_Form component and all it has to offer.

Zend_Form

Dragbox bridges command line and desktop

The GNU/Linux command line and desktop are both sophisticated interfaces, but they are mostly separate realities. You can drag text into a virtual terminal from the desktop, or use Edit -> Copy to move text in either direction, but by default moving files and directories between them is impossible -- a problem that often requires extra switching between them if you frequently work in both. Dragbox is designed to solve this problem and connect the two interfaces -- at least if one of them is GNOME -- through what might be described as a combination multiple clipboard and simple file manager.

Running the dragbox command opens a blank window on the desktop. Dragbox calls each running instance a shelf. If you choose, you can use the option --name name to name the shelf, which is handy if you plan to use multiple shelves. If you are really organized, you can use --title title to change the title bar, or add a text string immediately after the shelf's name that is immediately added to the shelf's list of clipboard items. Another alternative is to use dragbox -t "string" to add an item.

However, the real value of Dragbox is its ability to drag and drop files. By highlighting a text string, the name of a directory, or a list of files in the command line, you can drag and copy them directly into Dragbox. From there, you can drop them into an application in the same way that you would from the clipboard.

Dragbox's default behavior is to make a complete copy of a file you drag from the shelf. However, you also have several alternatives. By right-clicking in the Dragbox window and selecting Preferences from the menu, you can set the program to remove an item from its shelf after you copy it. Press Shift-Ctrl as you drag and you create a symbolic link instead of a complete copy.

Drag and drop in Dragbox also includes several navigation aids. If your keyboard layout or your modifications include an AltGr or super control key, you can press it to drag text from a window without making the window active, a convenient touch that can save you fumbling through a stack of open windows (although exactly how it accomplishes this feat, I'm not sure). Moreover, in the middle of a drag operation, you can hover the mouse cursor over the name of a window in the desktop panel's window list to display it. In exactly the same way, you can display another workspace by hovering over its name in the workspace switcher.

Going from the command line to the desktop, you can run any command against the contents of the active Dragbox shelf. You can use the --list option to display a list of shelves currently in use. To get a list of the contents of the current shelf in the command line, you can enter dragbox --get. By default, the output lists absolute paths, but you can add -u or --uris to see the paths as URIs instead. Generally, these options display their output immediately, but, if you prefer, you can use --write-on-exit to delay the display.

Perhaps Dragbox's most useful interaction is the ability to run a command against the contents of a shelf by piping it through xargs. For instance, if you wanted to back up the contents of the default shelf, you would use the command dragbox -0 | xargs -0 backupname.tar.gz to create a tar file. By using Dragbox as an intermediary in this way, you can quickly run a command using files and directories that are visible on the desktop without the trouble of having to remember or locate them on the command line.

Dragbox is only at version 0.3.0, and like any application still in early development, it has some limitations. Although its windows are listed on the panel the same as any open window, it would be less in the way if it were integrated as a drag-down display in the notification tray. A way to add formatted text -- perhaps in Open Document Format -- to a shelf would have the benefit of making Dragbox a multiple clipboard as well as a bridge between interfaces. The ability to save shelves for future sessions might also come in handy. Another simple enhancement would be to have the ability to click a directory or preview by default, instead of having to enable the option to view directories in a file manager in the preferences listed in the right-click menu. Those of us who regularly run a mixture of applications from different desktops would also appreciate the ability to use Dragbox with KDE or Xfce applications.

Still, these reservations aside, Dragbox is a simple but highly functional application that makes you aware of functionality that you never knew you were missing until you had it. Desktop users may find it a convenient multiple clipboard even if they never go near the command line. And if you are a person who moves regularly between the command line and the desktop, then 15 minutes of using Dragbox will probably be enough to make you wonder how you ever managed without it.

Bruce Byfield is a computer journalist who writes regularly for Linux.com and IT Manager's Journal.

Original link: http://www.linux.com/feature/132...

A Preview of Kernel-Based Mode-Setting

IconHave you ever been annoyed by Linux' lack of a coherent graphical boot process? Graphics hardware causing problems during sleep/wake cycles? Problematic virtual terminal switches? Kernel-based mode-setting, a new feature of Xorg still in heavy development aims to solve many of these problems by moving the mode-setting code from the user-space X driver into the Linux kernel. Phoronix takes a look at this new feature.

Currently, the only driver that supports kernel-based mode-setting is a special branch of the open source Intel video driver, and the only distribution that supports this new method of mode-setting is Fedora 9, of which a peview has been released (review). There is an effort under way to port the Radeon driver to kernel-based mode-setting too.

Phoronix explains the benefits of kernel-based mode-setting:

Suspend and resume support is improved with kernel mode-setting as the kernel no longer relies upon external resources for restoring the graphics adapters. With the process now being in-kernel, it's able to restore the mode automatically and more quickly. Likewise, virtual terminal switching is also improved as a result.

In addition to the above, the feature will also improve the debugging experience as graphical error messages can be displayed on the screen prior to the launch of the X server. You will also get a flicker-free graphical boot process, as the video mode needs to be set only once, instead of numerous times as is the case now (when the boot process starts and again when the X server finally loads).

Phoronix concludes that while still in its early stages, kernel-based mode setting will greatly improve the desktop Linux experience.

Kernel-based mode-setting is a great advancement for Linux and X.Org with it being a feature that delivers noticeable benefits to the end-user -- a cleaner flicker-free boot process, fast and reliable VT switching, improved suspend-and-resume support, and soon enough will be making fast-user-switching even faster. This is just the tip of the iceberg and more benefits, such as graphical diagnostic capabilities, should be able to flourish as a result of kernel-based mode-setting.

Original link: http://osnews.com/story/19661/A-...

IBM open collaboration client solution: Organizational planning and user segmentation for desktop migration

Level: Intermediate

Frank Heimes (frank.heimes@de.ibm.com), IT Architect, IBM

15 Apr 2008

Learn the steps involved in migrating your environment to that of a Linux client, including organizational planning and user segmentation. Based on customer experiences, this article offers a comprehensive guide to planning and executing your migration while minimizing disruption to your users.

Editor's note: This article is Part 2 of a four-part series. See the previous developerWorks article, "IBM open collaboration client solution: An introduction." Also, look for articles in the coming weeks on user segmentation and associated best practices (Part 3) and on highlights of various tools that let you migrate or access business-critical applications from Linux Desktops (Part 4).

Introduction

Migrations on the client-side are challenging due to their large scale, the potential uniqueness of each client system, and the direct effect on users. This article focuses on the starting point of a client migration: that is, the organizational planning and especially the user segmentation. It also offers a method to identify the most appropriate user segment that should be migrated first. Our systematic approach is based on several recent customer migration experiences. The technical planning process that seamlessly follows the organizational planning is the subject of the next article of this series.

Benchmarking Linux filesystems on software RAID 1

by Sander Marechal

A couple of months ago I got a couple of wonderful birthday presents. My lovely geeky girlfriend got me two Western Digital 500 GB SATA 3.0 drives, which were promptly supplemented with a 3ware 9550XS 4-port hardware RAID card. Immediately I came up with the idea for this article. I had just read up on mdadm software RAID so I though it would be perfect to bench mark the hardware RAID against the software RAID using all kinds of file systems, block sizes, chunk sizes, LVM settings, etcetera.

Or so I though… As it turns out, my (then) limited understanding of RAID and some trouble with my 3ware RAID cards meant that I had to scale back my benchmark quite a bit. I only have two disks so I was going to test RAID 1. Chunk size is not a factor when using RAID 1 so that axis was dropped from my benchmark. Then I found out that LVM (and the size of the extends it uses) are also not a factor, so I dropped another axis. And to top it off I discovered some nasty problems with 3ware 9550 RAID cards under Linux that quickly made me give up on hardware RAID. See The trouble with 3ware RAID below. I still ended up testing various filesystems using different blocksizes and workloads on an mdadm RAID 1 setup, so the results should still prove interesting.

Hardware used

I ran all of the benchmarks on my home server: A HP ProLiant ML370 G3. Here are the specs:

  • Dual Intel Xeon 3.2 Ghz with hyperthreading, 512 KiB L2 cache and 1 MiB L3 cache each (giving me four CPUs)
  • 1 GiB RAM
  • Adaptec AIC7XXX SCSI RAID with four 36.4 GiB disks in RAID 5 and two 18.2 GiB disks in RAID 1
  • 3ware 9550SXU 4-port SATA 3.0 RAID with two 500 GiB disks in JBOD, running in mdadm software RAID 1
  • Debian GNU/Linux 4.0 (Etch)
Finally, Secure Real-Time on the Desktop

Finally, secure real-time scheduling on the Linux desktop can be become a reality. Linux 2.6.25 gained Real-Time Group Scheduling, a feature which allows to limit the amount of CPU time real-time processes and threads may consume.

Traditionally on Linux real-time scheduling was limited to priviliged processes, because RT processes can lock up the machine if they enter a busy loop. Scheduling is effectively disabled for them -- they can do whatever they want and are (almost) never preempted by the kernel in what they are doing. In 2.6.12 RLIMIT_RTPRIO was introduced. It's a resource limit which opened up real-time scheduling for normal user processes. However the ability to lock up the machine for RT processes was not touched by this. When using /usr/security/limits.conf to raise this limit for specific users they'd gain the ability to lock up your machine.

Due to this raising this limit is a task that is left to the administrator on all current distros. Shipping a distro with the limit raised by default is shipping a distro where local users can easily freeze their machines.

It was always possible to write "watchdog" tools that could supervise RT processes by running on a higher RT priority and checking the CPU load imposed by the process on the system. However, to this point it was not possible in any way that would actually be secure (so that processes cannot escape the watchdog by forking), that wouldn't require lots of work in the watchdog (which is a bad idea since it runs at a very high RT priority, thus while it doing its stuff it will block the important RT processes from running), or that wouldn't be totally ugly.

Real-Time Group Scheduling solves the problem. It is now possible to create a cgroup for the processes to supervise. The processes cannot escape the cgroup by forking. Then, by manipulating the cpu.rt_runtime_us property of the cgroup a certain amount of RT CPU time can be assigned to the cgroup -- processes in the group cannot spend more time than this limit per one period of time. (The period length can be controlled globally via /proc/sys/kernel/sched_rt_period_us).

To demonstrate this I wrote a tool rtwatch which implements this technique in a watchdog tool that is SUID root, creates a cgroup, and forks off a user defined process inside, it with raised RLIMIT_PTPRIO but normal user priviliges. The child process can then acquire RT scheduling but never consume more CPU than allowed by the cgroup, with no option to lock up the machine anymore.

How to use this?

$ rtwatch 5 rtcpuhogger

This will start the process rtcpuhogger and grant it 5% of the available CPU time. To make sure that this is not misused by the user rtwatch will refuse to assign more than 50% CPU time to a single child. Since RT scheduling is all about determinism it is not possible to assign more than 100% CPU time (globally in sum) to all RT processes this way. Also, rtwatch will always make sure that 5% will be left for other tasks.

To work, rtwatch needs to run on Linux 2.6.25 with CONFIG_RT_GROUP_SCHED enabled. Unfortunately the Fedora kernel is not compiled this way, yet.

Why is all this so great? Those who attended my talk Practical Real-Time Programming in Userspace at Linux.conf.au 2008 (or watched the video) will know that besides the fact that I'd love to enable RT support for PulseAudio in Fedora in coming releases by default I'd also love to see RT programming more often used in desktop applications. Everywhere were the CPU time spent on a specific process should not depend on the overall system load, but solely on the time constraints of the job itself and what is process needs RT scheduling should be enabled. Examples for this are music or movie playback (the movie player should have enough time to decode one frame every 25th of a second, regardless what else is running on the system), fancy animations, quick reactions to user actions (i.e. updating the mouse cursor). All this for a machine that is snappier and more responsive with shorter latencies, regardless what else happens on the machine.

The day before yesterday, when Linux 2.6.25 was released, we came a big step closer to this goal.

Original link: http://0pointer.de/blog/projects...

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 SELinux
You 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.

Linux ServerLinux Server



# 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---



Live Class Descriptions:
Linux Server Management - course focus on running a Linux Server correctly (Ubuntu 8.04 or CentOS 5), see class outline below.
Linux Server Daemons - course focus on step-by-step install of servers (Ubuntu 8.04 or CentOS 5), installation and management of web servers, DNS servers, mail servers, DHCP,SSH, FTP,etc.

Self-Teach Packages:
Linux Server Management - course focus on running a Linux Server correctly (Ubuntu 8.04 or CentOS 5), see class outline below.
Linux Server Daemons - course focus on step-by-step install of servers (Ubuntu 8.04 or CentOS 5), installation and management of web servers, DNS servers, mail servers, DHCP,SSH, FTP,etc.

Getting help: the powerful man(ual)

Let’s face it: GNU/Linux software is not always easy to use. Especially command line software (at least the GUI programs have buttons and tooltips). Sometimes, the program will have a manual or some documentation at its homepage, but that is not always the case. The solution? The magical man.

man: the terminal solution to almost all problems

In the beginning, there was no coherent manual reading program. Manuals were scattered everywhere, if they even existed. Then, the first manual pages (shortened to man) were written by Dennis Ritchie (creator of the C language and UNIX pioneer) and Ken “ken” Thompson (creator of the B language which was surpassed by C and UNIX pioneer). Now, thirty-five years later, virtually every terminal program and most graphical programs have a manual in the manpage format.

You’re probably thinking, “fun history lesson, but this doesn’t help me at all”. Well, it’s now time to get to the program that was created to read these manuals: man. You don’t have to worry about installing it (if you are running an modern UNIX/Linux operating system, you have it installed). All you need to do is open a terminal and run man program_name_here, where program_name_here is the name of the program in lowercase (e.g. man firefox). You will then be presented with the program’s manual. You can use the arrow keys, the page up and page down keys, and the home and end keys to navigate. To exit, just hit the q key and you will be taken back to the console. Here’s what the first page of the wget manual looks like:

Checking Hard Disk Sanity With Smartmontools (Debian & Ubuntu)

Version 1.0
Author: Falko Timme
Last edited 04/08/2008

This guide shows how to install and use the smartmontools package on Debian Etch and Ubuntu 7.10. The smartmontools package provides utilities to check hard disks for disk degradation and failure, using the Self-Monitoring, Analysis and Reporting Technology System (SMART) built into most modern ATA and SCSI hard disks.

I do not issue any guarantee that this will work for you!

1 Installing Smartmontools

In order to install smartmontools, all we have to do is run:

apt-get install smartmontools

The smartmontools package comes with two utilities, smartctl which you can use to check your hard drives on the command line, and smartd, a daemon that checks your hard disks at a specified interval and logs warnings/errors to the syslog and can also send warnings and errors to a specified email address (usually the admin of the system).

2 Using Smartctl

Before we can use smartctl, we must find out how our hard disks are named. You can do this, for example, by running:

df -h

or

fdisk -l

server1:~# fdisk -l

Disk /dev/hda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 19269 154778211 83 Linux
/dev/hda2 19270 19457 1510110 5 Extended
/dev/hda5 19270 19457 1510078 82 Linux swap / Solaris
server1:~#

Recovering Corrupted VMware Disk Images

Many a time I cursed and vailed because VMware had let me down. Here is a "quick" and dirty way to access your corrupted VMware server/workstation .vmdk files.

Here is how I managed to recover Zimbra mail servers "mail folders" (Ubuntu6/ext3) from corrupted VMware server image using WindowsXP, VMware Server, Ken Kato's "Virtual Disk Driver for Windows NT platform" & Diskinternals Linux reader.

1) Copy corrupted .vmdk file to your WindowsXP workstations c:\temp folder. My filename was Opt.vmdk - I had to use WinSCP without any compression on the Linux side to copy it to Windows.

2) Download Ken's "Virtual Disk Driver" (VDK) and extract it to c:\temp folder. (Freeware) - http://chitchat.at.infoseek.co.jp/vmware/vdk.html

3) Type

CMD

in the "Run" on Windows to start the "Command Prompt".

4) Change to the folder where vdk.exe is located using

cd c:\temp

command.

5) Type

vdk start

6) Type

vdk open 0 <diskfile> /L:R:

-My command was

vdk open 0 Opt.vmdk /L:R:

<diskfile> has to be substituted by the vmdk file. In my case it was the opt.vmdk file which then was mounted. /L:R: = Mount it as drive R:.

7) Now you probably have the disk mounted on your Windows PC. Problem is that your Windows does not understand Linux formated drives yet.

8) Download and install "Disk Internals Linux Reader." (Demoversion.) - http://www.diskinternals.com/download.shtml#cd

9) When I started the Linux Reader it crashed, but I just ignored that and continued. It was still able to find my mounted Linux drive. After scanning the drive in vain I cancelled all the scans and just proceeded to restore the folders it found to the Windows local hard drive.

Hope this helps. VMware Server's own recovery/mount tools did not work out well for me.

Sami Mattila
http://www.mattila.eu
 

Original link: http://www.howtoforge.com/recove...