在webmin設定DNS

http://antoinecafe.blogspot.tw/2004/09/webmindns.html

啟用 chroot 功能後, 所有與該程式運作相關的檔案必須全部移至更改後的根目錄下。以此版 BIND 為例, 所有設定檔及記錄檔都必須以 /var/named/chroot 為根目錄, 搬到該目錄下 (檔案的內容則不需更改)。相關檔案要擺位的位置, 請參考下表： 相關檔案名稱 啟用 chroot 前檔案 (絕對) 位置 啟用 chroot 後檔案 (絕對) 位置 
工作環境設定檔 
/etc/named.conf 
/var/named/chroot/etc/named.conf 

根網域記錄檔 
/var/named/named.ca 
/var/named/chroot/var/named/named.ca 

本機正解記錄檔 
/var/named/localhost.zone 
/var/named/chroot/var/named/localhost.zone 

本機反解記錄檔 
/var/named/named.local 
/var/named/chroot/var/named/named.local 

網域正解記錄檔 
/var/named/named.flag.com.tw 
/var/named/chroot/var/named/named.flag.com.tw 

網域反解記錄檔 
/var/named/named.203.74.205 
/var/named/chroot/var/named/named.203.74.205 

intent中的俩方法区别

http://zhouxun1026.iteye.com/blog/1618618

public Intent putExtra (String name, double[] value)
设置方法 intent.putExtra("aaa", "bbbb");
获取方法 this.getIntent().getCharSequenceExtra("aaa")

public Intent putExtras (Bundle extras)

设置方法
Bundle bd = new Bundle();
bd.putString("aaa",“bbbb”);
intent.putExtras(bd);
获取方法
Bundle bd=this.getIntent().getExtras();
bd.getString("aaa"));


总结：带s的得通过个Bundle来绑定数据

轉貼 Log4j

http://werdna1222coldcodes.blogspot.tw/2009/11/javalog4j.html

http://my.so-net.net.tw/idealist/Java/Log4j.html

Lifecycle Flow

Here are the primary processes involved in cloud-to-device messaging:

• Enabling GCM. An Android application running on a mobile device registers to receive messages.
• Sending a message. A 3rd-party application server sends messages to the device.
• Receiving a message. An Android application receives a message from a GCM server.

These processes are described in more detail below.

Enabling GCM

This is the sequence of events that occurs when an Android application running on a mobile device registers to receive messages:

1. The first time the Android application needs to use the messaging service, it fires off a registration Intent to a GCM server.
   This registration Intent (com.google.android.c2dm.intent.REGISTER) includes the sender ID(註冊後網址列上的ProjectID), and the Android application ID.(APP名稱)
   Note: Because there is no lifecycle method that is called when the application is run for the first time, the registration intent should be sent on onCreate(), but only if the application is not registered yet.
2. If the registration is successful, the GCM server broadcasts a com.google.android.c2dm.intent.REGISTRATION intent which gives the Android application a registration ID.
   The Android application should store this ID for later use (for instance, to check on onCreate() if it is already registered). Note that Google may periodically(定期) refresh the registration ID, so you should design your Android application with the understanding that the com.google.android.c2dm.intent.REGISTRATION intent may be called multiple times. Your Android application needs to be able to respond accordingly.
3. To complete the registration, the Android application sends the registration ID to the application server. The application server typically通常 stores the registration ID in a database.

The registration ID lasts持續 until the Android application explicitly明確地
 unregisters itself, or until Google refreshes the registration ID for your Android application.

Note: When users uninstall an application, it is not automatically unregistered on GCM. It is only unregistered when the GCM server tries to send a message to the device and the device answers that the application is uninstalled. At that point, you server should mark the device as unregistered (the server will receive a NotRegistered error).

Note that it might take a few minutes for the registration ID to be completed removed from the GCM server. So if the 3rd party server sends a message during this time, it will get a valid message ID, even though the message will not be delivered to the device.

Architectural Overview

Architectural Overview

---

This section gives an overview of how GCM works.
This table summarizes the key terms and concepts involved in GCM. It is divided into these categories:

• Components — The physical entities that play a role in GCM.
• Credentials — The IDs and tokens that are used in different stages of GCM to ensure that all parties have been authenticated, and that the message is going to the correct place.

Components
Mobile Device	The device that is running an Android application that uses GCM. This must be a 2.2 Android device that has Google Play Store installed, and it must have at least one logged in Google account if the device is running a version lower than Android 4.0.4. Alternatively, for testing you can use an emulator running Android 2.2 with Google APIs.
3rd-party Application Server	An application server that developers set up as part of implementing GCM in their applications. The 3rd-party application server sends data to an Android application on the device via the GCM server.
GCM Servers	The Google servers involved in taking messages from the 3rd-party application server and sending them to the device.
Credentials
Sender ID	A project ID you acquire from the API console, as described in Getting Started. The sender ID is used in the registration process to identify an Android application that is permitted to send messages to the device.
Application ID	The Android application that is registering to receive messages. The Android application is identified by the package name from the manifest. This ensures that the messages are targeted to the correct Android application.
Registration ID	An ID issued by the GCM servers to the Android application that allows it to receive messages. Once the Android application has the registration ID, it sends it to the 3rd-party application server, which uses it to identify each device that has registered to receive messages for a given Android application. In other words, a registration ID is tied to a particular Android application running on a particular device.
Google User Account	For GCM to work, the mobile device must include at least one Google account if the device is running a version lower than Android 4.0.4.
Sender Auth Token	An API key that is saved on the 3rd-party application server that gives the application server authorized access to Google services. The API key is included in the header of POST requests that send messages.

GCM Architectural Overview

Quickview

• Get an introduction to key GCM terms and concepts.
• Learn the basic features of a GCM application.
• Understand the role of the 3rd-party application server, and how to send messages and process results.

In this document

1. Introduction
2. Architectural Overview
   1. Lifecycle Flow
   2. What Does the User See?
3. Writing Android Applications that use GCM
   1. Creating the Manifest
   2. Registering for GCM
   3. Unregistering from GCM
   4. Handling Intents sent by GCM
      1. Handling Registration Results
      2. Handling Received Data
   5. Developing and Testing Your Android Applications
4. Role of the 3rd-party Application Server
   1. Sending Messages
      1. Request format
      2. Response format
5. Viewing statistics
6. Examples

Google Cloud Messaging for Android (GCM) is a free service that helps developers send data from servers to their Android applications on Android devices. This could be a lightweight message telling the Android application that there is new data to be fetched from the server (for instance, a movie uploaded by a friend), or it could be a message containing up to 4kb of payload data (so apps like instant messaging can consume the message directly). The GCM service handles all aspects of queueing of messages and delivery to the target Android application running on the target device.

To jump right into using GCM with your Android applications, see the instructions in Getting Started.

Introduction

---

Here are the primary characteristics of Google Cloud Messaging (GCM):

• It allows 3rd-party application servers to send messages to their Android applications.
• GCM makes no guarantees about delivery or the order of messages.
• An Android application on an Android device doesn't need to be running to receive messages. The system will wake up the Android application via Intent broadcast when the message arrives, as long as the application is set up with the proper broadcast receiver and permissions.
• It does not provide any built-in user interface or other handling for message data. GCM simply passes raw message data received straight to the Android application, which has full control of how to handle it. For example, the application might post a notification, display a custom user interface, or silently sync data.
• It requires devices running Android 2.2 or higher that also have the Google Play Store application installed, or or an emulator running Android 2.2 with Google APIs. However, you are not limited to deploying your Android applications through Google Play Store.
• It uses an existing connection for Google services. For pre-3.0 devices, this requires users to set up their Google account on their mobile devices. A Google account is not a requirement on devices running Android 4.0.4 or higher.

using plain text

If you are using plain text instead of JSON, the message fields must be set as HTTP parameters sent in the body, and their syntax is slightly different, as described below:

Field	Description
registration_id	Must contain the registration ID of the single device receiving the message. Required.
collapse_key	Same as JSON (see previous table). Optional.
data.<key>	Payload data, expressed as parameters prefixed with data. and suffixed as the key. For instance, a parameter of data.score=3x1 would result in an intent extra named score whose value is the string 3x1. There is no limit on the number of key/value parameters, though there is a limit on the total size of the message. Note that the key cannot be a reserved word (from or any word starting with google.). Optional.
delay_while_idle	Should be represented as 1 or true for true, anything else for false. Optional. The default value is false.
time_to_live	Same as JSON (see previous table). Optional.

If you want to test your request (either JSON or plain text) without delivering the message to the devices, you can set an optional HTTP parameter called dry_run with the value true. The result will be almost identical to running the request without this parameter, except that the message will not be delivered to the devices. Consequently, the response will contain fake IDs for the message and multicast fields (see Response format).