XinSpace

use the following before you start your query

mysql_query(“SET CHARACTER SET utf8″, $connection);

http://www.cyberciti.biz/tips/force-iptables-to-log-messages-to-a-different-log-file.html

According to man page:
Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. Several different tables may be defined. Each table contains a number of built-in chains and may also contain user defined chains.

By default, Iptables log message to a /var/log/messages file. However you can change this location. I will show you how to create a new logfile called /var/log/iptables.log. Changing or using a new file allows you to create better statistics and/or allows you to analyze the attacks.

Iptables default log file

For example, if you type the following command, it will display current iptables log from /var/log/messages file:
# tail -f /var/log/messages
Output:

Oct  4 00:44:28 debian gconfd (vivek-4435): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2
Oct  4 01:14:19 debian kernel: IN=ra0 OUT= MAC=00:17:9a:0a:f6:44:00:08:5c:00:00:01:08:00 SRC=200.142.84.36 DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=18374 DF PROTO=TCP SPT=46040 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Oct  4 00:13:55 debian kernel: IN=ra0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:18:de:55:0a:56:08:00 SRC=192.168.1.30 DST=192.168.1.255LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=13461 PROTO=UDP SPT=137 DPT=137 LEN=58

Procedure to log the iptables messages to a different log file

Open your /etc/syslog.conf file:
# vi /etc/syslog.conf
Append following line
kern.warning /var/log/iptables.log
Save and close the file.

Restart the syslogd (Debian / Ubuntu Linux):# /etc/init.d/sysklogd restartOn the other hand, use following command to restart syslogd under Red Hat/Cent OS/Fedora Core Linux:# /etc/init.d/syslog restart

Now make sure you pass the log-level 4 option with log-prefix to iptables. For example:
# DROP everything and Log it
iptables -A INPUT -j LOG –log-level 4
iptables -A INPUT -j DROP

For example, drop and log all connections from IP address 64.55.11.2 to your /var/log/iptables.log file:
iptables -A INPUT -s 64.55.11.2 -m limit –limit 5/m –limit-burst 7 -j LOG –log-prefix ‘** HACKERS **’–log-level 4
iptables -A INPUT -s 64.55.11.2 -j DROP


Where,

• –log-level 4: Level of logging. The level # 4 is for warning.
• –log-prefix ‘*** TEXT ***’: Prefix log messages with the specified prefix (TEXT); up to 29 letters long, and useful for distinguishing messages in the logs.

You can now see all iptables message logged to /var/log/iptables.log file:
# tail -f /var/log/iptables.log

Updated for accuracy.

Solution:

Edit the file “serverfilesExcelServer.xml” under C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\XML

Comments this line:

<Mapping FileExtension=”xlsx” RedirectUrlTemplate= “/_layouts/xlviewer.aspx?id=|0″ NoGetRedirect=”TRUE”/>

http://technet.microsoft.com/en-us/library/cc263467.aspx

System Seven sends SMS to this number without asking permission.
This is the worst software I have ever used on my E71

this is caused by the cartage return on the ending of first line. To fix this, you can

1. add -w to the end of the line. make it #!/usr/bin/perl -w

or

2. $ perl -pi.bak -e ’s/ 15//’ *.pl

This error happens on a SharePoint 2007 server, the web services is accessed by an alias url which does not exist in DNS. And we put a host name into our server’s HOSTS file

127.0.0.1 alias

and one of our applications accesses http://alias/_vti_bin/Lists.asmx on the server programmically. The application fails because it gets 401 access denied from IIS.

In the security eventlog, I saw the following event

Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 537
Date: Date
Time: Time
User: NT AUTHORITY\SYSTEM
Computer: Computer_Name
Description: Logon Failure:
Reason: An error occurred during logon
User Name: User_Name
Domain: Domain_Name
Logon Type: 3
Logon Process: Ðùº
Authentication Package: NTLM
Workstation Name: Computer_Name
Status code: 0xC000006D
Substatus code: 0×0
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: IP_Address
Source Port: Port_Number

After some research, I found this problem was related with this article by Microsoft http://support.microsoft.com/default.aspx?scid=kb;en-us;896861#top

This issue occurs if you install Microsoft Windows XP Service Pack 2 (SP2) or Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows XP SP2 and Windows Server 2003 SP1 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.

Microsoft claims this security update http://support.microsoft.com/kb/957097/ could have caused the issue.  I checked the log of this server and found this security update was installed on 12/4/2008. It roughly matches the time when the problem was first noticed.

I have a chance to try the feature Document Conversion of SharePoint Server 2007. It works pretty well. All formats are preserved. I used to copy text directly from a word document to a Publishing Page, which was ok not but great: It added an additional line to each paragraph. this Word Document to Web Page conversion does not leave an extra line so I say it is better.

However I encoutered a problem when I tried to update my original word document by uploading a new version. The following error is through: Isn’t it supposed to update the existing web page as well by adding a new version? According to Microsoft, it should. I suspect there is a bug here. When a new version is added, the relationship between Source and Destination Document breaks. The data (of Destination) is erased when source document is updated.

There is another way to bypass this bug though. The destination document still contains data of the relationship, you can go another way around by updating Web Page from its source. Simply go to the Web Page converted from the word document, click Edit, then from the top edit bar, choose Update Content From Source.

The backup file is corrupt and cannot be restored. It was a huge backup, about 3G. Well, tried to re-do the backup, then did another restore and it was good.

Lession Learned: Never rely on the single source backup from stsadm.

this problem only occurs on Report Center template.  Looks like a bug to me.