April 2013

Changing The Site URL wordpress

  • Published in Wordpress
  • April 30, 2013

On the Settings->General screen in a single site installation of WordPress, there are two fields named "WordPress address (URL)" and "Site address (URL)". These are also known as the "Home" and "Site URL" settings. They are important settings, since they control where WordPress thinks your site is located. They control the display of the URL in the admin section of your page as well as the front end, and are used throughout the WordPress code.

  • The "Home" setting is the address you want people to type in their browser to reach your WordPress blog.
  • The "Site URL" setting is the address where your WordPress core files reside.

Note: Both settings should include the http:// part and should not have a slash "/" at the end.

Every once in a while, somebody finds a need to manually change (or fix) these settings. Usually this happens when they change one or both and discover that their site no longer works properly. This can leave the user with no easily discoverable way to correct the problem. This article tells you how to change these settings directly.

Additional information is presented here for the case where you are moving WordPress from one site to another, as this will also require changing the site URL. You should not attempt to use this additional information if you're only attempting to correct a "broken" site.

Alert! These directions are for single installs of WordPress only. If you are using WordPress MultiSite, you will need to manually edit your database.

Contents

[hide]

 

Changing the Site URL

There are four easy methods to change the Site URL manually. Any of these methods will work and perform much the same function.

Edit wp-config.php

It is possible to set the site URL manually in the wp-config.php file.

Add these two lines to your wp-config.php, where "example.com" is the correct location of your site.

define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');

This is not necessarily the best fix, it's just hardcoding the values into the site itself. You won't be able to edit them on the General settings page anymore when using this method.

Edit functions.php

If you have access to the site via FTP, then this method will help you quickly get a site back up and running, if you changed those values incorrectly.

1. FTP to the site, and get a copy of the active theme's functions.php file. You're going to edit it in a simple text editor (like notepad) and upload it back to the site.

2. Add these two lines to the file, immediately after the initial "<?php" line.

update_option('siteurl','http://example.com/blog');
update_option('home','http://example.com/blog');

Use your own URL instead of example.com, obviously.

3. Upload the file back to your site, in the same location. FileZilla offers a handy "edit file" function to do all of the above rapidly; if you can use that, do so.

4. Load the login or admin page a couple of times. The site should come back up.

5. Repeat the above steps, but remove those lines. IMPORTANT: Do NOT leave those lines in there. Remove them immediately after the site is up and running again.

If there is no functions.php file in the theme:

Create a new text file called "functions.php".

Edit it with notepad, and add this text to it, using your own URL instead of example.com:

<?php
update_option('siteurl','http://example.com/blog');
update_option('home','http://example.com/blog');
?>

Upload that to your theme directory, then proceed as stated above. Remove the file afterwards.

>>>

Here are some additional details that step you through transfering a LAN-based wordpress site into an externally accessible site as well enabling editing the wordpress site from inside the LAN.

Two important keys are router/firewall modifications and the "wait 10+ minutes" after making the changes at the end.

-using ssh to log into your server (nano is a server preinstalled text editor)
-$ nano /var/www/books/wp-content/themes/twentyeleven/functions.php
-add lines just after <?php

    update_option('siteurl','http://your.site.url:port/yourblog');
    update_option('home','http://your.site.url:port/yourblog');

-refresh your web browser using your external site url

   http://your.site.url:port/yourblog

-$ nano /var/www/books/wp-content/themes/twentyeleven/functions.php
-remove those lines you just added (or comment them out)
-access your router (these steps are for pfSense, other routers should have similar settings to look for/watch out for)
-add to firewall/nat table a line like this

        wan/tcp/port/LAN.server.IP/80

-add to firewall/rules table a line like this

        tcp/*/port/LAN.server.IP/port/*

-uncheck the box at System/advanced/network address translation/Disable NAT Reflection

       "Disables the automatic creation of NAT redirect rules for access to your public IP addresses from within your internal networks. Note: Reflection only works on port forward type items and does not work for large ranges > 500 ports."

Then go do something for ten minutes and when you get back see if the external urlhttp://your.site.url:port/yourblog from a LAN browser brings the page up correctly.

Relocate method

WordPress supports an automatic relocation method intended to be a quick assist to getting a site working when relocating a site from one server to another.

Steps

1. Edit the wp-config.php file.

2. After the "define" statements (just before the comment line that says "That's all, stop editing!"), insert a new line, and type: define('RELOCATE',true);

3. Save your wp-config.php file.

4. Open a web browser and manually point it to wp-login.php on the new server. For example, if your new site is at http://www.mynewdomain.com, then type http://www.mynewdomain.com/wp-login.php into your browser's address bar.

5. Login as per normal.

6. Look in your web browser's address bar to verify that you have, indeed, logged in to the correct server. If this is the case, then in the Admin back-end, navigate to Settings > General and verify that both the address settings are correct. Remember to Save Changes.

7. Once this has been fixed, edit wp-config.php and either completely remove the line that you added (delete the whole line), comment it out (with //) or change the true value to false if you think it's likely you will be relocating again.

Note: When the RELOCATE flag is set to true, the Site URL will be automatically updated to whatever path you are using to access the login screen. This will get the admin section up and running on the new URL, but it will not correct any other part of the setup. Those you will still need to alter manually.

Changing the URL directly in the database

If you know how to access phpMyAdmin on your host, then you can edit these values directly to get you up and running again.

  1. Backup your database and save the copy off-site.
  2. Login to phpMyAdmin.
  3. Click the link to your Databases.
  4. A list of your databases will appear. Choose the one that is your WordPress database.
  5. All the tables in your database will appear on the screen.
  6. From the list, look for wp_optionsNote: The table prefix of wp_ may be different if you changed it when installing.
  7. Click on the small icon indicated as Browse.
  8. A screen will open with a list of the fields within the wp_options table.
  9. Under the field option_name, scroll down and look for siteurl.
  10. Click the Edit Field icon which usually is found at the far left at the beginning of the row.
  11. The Edit Field window will appear.
  12. In the input box for option_value, carefully change the URL information to the new address.
  13. Verify this is correct and click Go to save the information.
  14. You should be returned to your wp_options table.
  15. Look for the home field in the table and click Edit FieldNote There are several pages of tables insidewp_options. Look for the > symbol to page through them.
  16. In the input box for option_value, carefully change the URL information to the new address.
  17. Verify this is correct and click Go to save the information.

Moving Sites

When moving sites from one location to another, it is sometimes necessary to manually modify data in the database to make the new site URL information to be recognized properly. Many tools exist to assist with this, and those should generally be used instead of manual modifications.

This is presented here as information only. This data may not be complete or accurate.

You should read the Moving WordPress article first, if attempting to move WordPress from one system to another.

Altering Table Prefixes

Like many WordPress administrators, you may be running several WordPress installations off of one database using various wp-config.php hacks. Many of these hacks involve dynamically setting table prefixes, and if you do end up altering your table prefix, you must update several entries within the prefix_usermeta table as well.

As in the above section, remember that SQL changes are permanent and so you should back up your database first:

If you are changing table prefixes for a site, then remember to alter the table prefix in the usermeta tables as well. This will allow the new site to properly recognize user permissions from the old site.

UPDATE `newprefix_usermeta` SET `meta_key` = REPLACE( `meta_key` , 'oldprefix_', 'newprefix_' );

Changing Template Files

In your WordPress Theme, open each template file and search for any manually entered references to your old domain name and replace it with the new one. Look for specific hand coded links you may have entered on the various template files such as the sidebar.php and footer.php.

WordPress uses a template tag called bloginfo() to automatically generate your site address from information entered in your Administration > Settings > General panel. The tag in your template files will not have to be modified.

Changing the Config file

You will need to update your WordPress configuration file if your database has moved or changed in certain ways.

  1. You will only need to modify the config file if:
    1. your database has moved to another server and is not running on your localhost
    2. you have renamed your database
    3. you have changed the database user name
  2. "'Make a backup copy of your wp-config.php file.'"
  3. Open the wp-config.php file in a text editor.
  4. Review its contents. In particular, you are looking for the database host entry.
  5. Save the file.

At this point, your WordPress blog should be working.

Verify the Profile

  1. In your Administration Panels go to Settings > General . Here you will verify that the changes you made inChanging the URL above, are correct.
  2. Verify that the reference in your WordPress URL contains the new address.
  3. Verify that the reference in your "Blog URL" contains the new address.
  4. If you have made changes, click Save Changes.

Changing the .htaccess file

After changing the information in your Administration > Settings > General panel, you will need to update your.htaccess file if you are using Permalinks or any rewrites or redirects.

  1. Make a backup copy of your .htaccess file. This is not a recommendation but a requirement.
  2. Open the .htaccess file in a text editor.
  3. Review its contents, looking for any custom rewrites or redirects you entered. Copy these to another text file for safe keeping.
  4. Close the file.
  5. Follow the instructions on the Permalinks SubPanel for updating your Permalinks to the .htaccess file.
  6. Open the new .htaccess file and check to see if your custom rewrites and redirects are still there. If not, copy them from the saved file and paste them into the new .htaccess file.
  7. Make any changes necessary in those custom rewrites and redirects to reflect the new site address.
  8. Save the file.
  9. Test those redirects to ensure they are working.

If you make a mistake, you can Restoring Your Database From Backup from your backup and try this again. So make sure it is right the first time.

Additional items of note

There are other things you may wish to change in order to correct URLs when moving sites.

  1. Images link: image links are stored in "post_content" in the wp_posts table. You can use the similar code above to update image links.
  2. wp_options: Besides the "siteurl" and "home" items mentioned above, there are other option_value which also need revision, such as "upload path", and some plugin items (depends on what you've installed, such as widgets, stats, DMSGuestbook, sitemap, etc.)
  3. To fix widgets that contain outdated URL's, you may edit them in Dashboard / Appearance / Widgets.
  4. Fix the Incoming Links URL. This one is easy to miss. Look on the main Dashboard screen, at Incoming Links. Hover over the area to the right of "Incoming Links" to reveal the "Configure" link. Edit the URL to reflect the new site address.
  5. Do a FULL database search for any items left. MAKE SURE you know what you are changing. and go through each item for possible improper replacement.
  6. If you a running a network / have multiple sites, you will need to replace instances of the URL in the database. They are stored in many tables, including each one of the sites (blogs). Be careful in what you replace and be sure you know the meaning of the field before changing it. See the Important GUID note below for an example of what not to change.

How To: Move Your WordPress Blog to a New Domain - Using the Export/Import feature to move a blog to a new domain

Important GUID Note

When doing the above and changing the URLs directly in the database, you will come across instances of the URL being located in the "guid" column in the wp_posts tables.

It is critical that you do NOT change the contents of this field.

The term "GUID" stands for "Globally Unique Identifier". It is a field that is intended to hold an identifier for the post which a) is unique across the whole of space and time and b) never, ever changes. The GUID field is primarily used to create the WordPress feeds.

When a feed-reader is reading feeds, it uses the contents of the GUID field to know whether or not it has displayed a particular item before. It does this in one of various ways, but the most common method is simply to store a list of GUID's that it has already displayed and "marked as read" or similar.

Thus, changing the GUID will mean that many feedreaders will suddenly display your content in the user's reader again as if it was new content, possibly annoying your users.

In order for the GUID field to be "globally" unique, it is an accepted convention that the URL or some representation of the URL is used. Thus, if you own example.com, then you're the only one using example.com and thus it's unique to you and your site. This is why WordPress uses the permalink, or some form thereof, for the GUID.

However, the second part of that is that the GUID must never change. Even if you shift domains around, the post is still the same post, even in a new location. Feed readers being shifted to your new feeds when you change URLs should still know that they've read some of your posts before, and thus the GUID must remain unchanged.

Never, ever, change the contents of the GUID column, under any circumstances.

One exception is attachment media: Attachment media locations are stored as a URL in the GUID. If the default uploads folder needs to be changed to a different location, then the media URL will need to be changed in the post_content and guid columns of the posts table. For example, if the default uploads folder is changing from wp-content/uploads to images:

UPDATE wp_posts SET post_content = REPLACE(post_content,'www.domain.com/wp-content/uploads','www.domain.com/images');
UPDATE wp_posts SET guid = REPLACE(guid,'www.domain.com/wp-content/uploads','www.domain.com/images');
Read more...

php 表格 foreach 显示 select 结果

  • Published in PHP
  • April 29, 2013
<?php
$con = mysql_connect("localhost","tdg","tdg");
if (!$con)
  {
  die('Could not connect: ' . mysql_error());
  }

mysql_select_db("tdg", $con);

$result = mysql_query("SELECT * FROM  `client`");
?>

<table border="2">
    <?php while ($row = mysql_fetch_assoc($result)): ?>
    <tr>
        <?php foreach($row as $key=>$value) {   
            echo "<td>$key: $value</td>\n "; 
        } ?> 
    </tr>          
    <?php endwhile; ?>
</table>
<?php
mysql_close($con);
?>
Read more...

Single Sign-On installation for non-English upgrade of vCenter Server (2037976)

Details

If you use vSphere 5.1 Single Sign-On (SSO) on a German, French, Simplified Chinese, Korean, or Japanese Windows operating system, you may experience these symptoms:
  • Upgrading SSO to vSphere 5.1.0a or 5.1.0b with the UI fails
  • You see the error:

    Error 2229

  • This issue may also occur when using a mounted ISO

Solution

The SSO installer halts on German, French, Korean, Simplified Chinese, and Japanese Windows operating systems due to an incompatibility with the Microsoft Software Installer.

To work around this issue, use VMware's command-line options to silently upgrade the SSO installation from 5.1 to 5.1.0a or 5.1.0b.

Note: Other components of vSphere 5.1.0a or 5.1.0b can be successfully upgraded using the UI. However, VMware recommends using the independent installers for upgrades rather than the simple installer.

To use the command line for the upgrade:

  1. On the Windows system running vSphere 5.1 SSO, launch a command-line prompt as Administrator or as a user with privileges to modify/install SSO.

  2. From the command-line, navigate to the folder containing the 5.1.0a or 5.1.0b SSO installer executable, VMware-SSO-Server.exe.

  3. To perform a silent upgrade, run the command:

    executable_name /S /v"/L*v log_location /qn"

    For example, run this command to perform a silent SSO command-line upgrade:

    VMware-SSO-Server.exe /S /v"/L*v \"%temp%\vim-sso-msi.log\" /qn"

Note: This upgrade does not produce any UI dialog box or other UI interactions. See the user-specified log during this process for a status update. The log file indicates when the SSO component upgrade is complete.


Additional Information

To be alerted when this article is updated, click Subscribe to Document in the Actions box.

Read more...

PuTTYgen

  • Published in CentOS 6
  • April 19, 2013

PuTTYgen

PuTTYgen 是一套可以產生金鑰的工具,它可生成 RSA 以及 DSA 的金鑰, 做出來的公開以及私有金鑰,可以用於 PuTTY 、 PSCP 、 Plink 以及 Pageant 。

    • 產生一個新的金鑰 :

  1. 直接點選 PuTTYgen 圖示。

  2. 第一步,選擇所要生成之金鑰的演算法 (RSA / DSA) 、 SSH 版阿本以及金鑰的長度,如下圖所示。 

  3. 按下後,在下圖所表示的紅框內任意移動滑鼠, 直到金鑰產生結束,此時,電腦會收集滑鼠任意移動所得到的資訊,最為產生金鑰的亂數依據,如下圖。

  4. 產生完後,可更改金鑰的備註,另外請任意輸入自己不易忘記的句子,做為啟動私鑰的通行碼之用,之後將私鑰儲存在安全的地方,如下圖所示。

  • 以下將講解上述過程中遇到的各個選項及其代表意義:

    • 生成之金鑰的演算法:

  1. SSH 1 協定僅能使用 RSA 做為生成金鑰的演算法,而 SSH 2 協定能夠支援 RSA 以及 DSA 兩種演算法。

  2. PuTTY 的作者強烈建議使用者使用 RSA 來生成金鑰,因為 DSA 有一些設計不良的地方,可能會導致是用者的私鑰被有心人士竊聽,倘若非要使用 DSA 時,也請不要在每台遠端伺服機使用同樣的金鑰。

  • 金鑰的長度:

長度越長,相對而言,也就更為安全,但對於大部分的情況之下, 1024 bit 已經很足夠。

  • 啟動私鑰:

當儲存私鑰至近端電腦時,若沒有輸入通行碼 (passphrase) ,則私鑰不會再被加密,意指任何人若取得此私鑰則對方將聽行無阻。若在儲存之際,有事先輸入自己熟記的一串通行碼,則就算私鑰被拿走,對方也無法取用其中的內容。

請記住你的通行碼,它並無法經由其他方式取得它。

  • 關於相容性的問題:

  • 大部分的 SSH 1 client 使用標準定義的私鑰, PuTTY 也是依照標準來執行,所以不會有與其他的 SSH client 相衝突。

  • 然而 SSH 2 的私鑰並沒有一個標準的格式,所以任一套軟體 (PuTTY 、 OpenSSH 、 ssh.com) 生成的金鑰無法立刻在其他套軟體上執行。

PuTTYgen 能夠將私鑰輸出成 OpenSSH 以及 ssh.com 的格式,請先下載最新測試版的 PuTTYgen ,先將私鑰匯入 PuTTYgen 後,在 Converstions 中選擇所要輸出的格式,在儲存新的私鑰之前,請先移除通行碼。

    • 如何利用金鑰來提供連線認證:

  • 如果你使用 SSH 1 協定,請先至遠端家目錄的 .ssh 目錄,以文字編輯器開啟檔案 authorized_keys ,先暫時回到近端電腦,使用 PuTTYgen 載入所儲存之私鑰,載入後,請將上圖黃色框框內的所有文字複製,再回到 authorized_keys 檔案中,將複製內的東西全部貼上,存檔離開即可。

  • 倘若遠端伺服機提供的是早期版本的 OpenSSH 2 ,先前的檔案要改名為 authorized_keys2 。

  • 如果遠端伺服機為 ssh.com ,你必須先將轉換過公鑰上傳至家目錄的 .ssh2 目錄,並且編輯檔案 authorization ,在檔案中尋找一行開頭為 key ,並且將 key 後面的檔案名稱更改成你剛剛上傳的公鑰檔案名。

  • 請注意位於家目錄的 .ssh 目錄的檔案權限及屬性,它僅可以讓自己寫入。

     

Read more...

Using Rsync and SSH

  • Published in CentOS 6
  • April 19, 2013
This document covers using cron, ssh, and rsync to backup files over a local network or the Internet. Part of my goal is to ensure no user intervention is required when the computer is restarted (for passwords, keys, or key managers).
I like to backup some logging, mail, and configuration information sometimes on hosts across the network and Internet, and here is a way I have found to do it. You'll need these packages installed:
  • rsync
  • openssh
  • cron (or vixie-cron)
Please note these instructions may be specific to Red Hat Linux versions 7.3, 9, and Fedora Core 3, but I hope they won't be too hard to adapt to almost any *NIX type OS. The man pages for 'ssh' and 'rsync' should be helpful to you if you need to change some things (use the "man ssh" and "man rsync" commands).
First, I'll define some variables. In my explanation, I will be synchronizing files (copying only new or changed files) one way, and I will be starting this process from the host I want to copy things to. In other words, I will be syncing files from /remote/dir/ on remotehost, as remoteuser, to /this/dir/ on thishost, as thisuser.
I want to make sure that 'rsync' over 'ssh' works at all before I begin to automate the process, so I test it first as thisuser:
$ rsync -avz -e ssh remoteuser@remotehost:/remote/dir /this/dir/ 
and type in remoteuser@remotehost's password when prompted. I do need to make sure that remoteuser has read permissions to /remote/dir/ on remotehost, and that thisuser has write permissions to /this/dir/ onthishost. Also, 'rsync' and 'ssh' should be in thisuser's path (use "which ssh" and "which rsync"), 'rsync' should be in remoteuser's path, and 'sshd' should be running on remotehost.
Configuring thishost

If that all worked out, or I eventually made it work, I am ready for the next step. I need to generate a private/public pair of keys to allow a 'ssh' connection without asking for a password. This may sound dangerous, and it is, but it is better than storing a user password (or key password) as clear text in the script [0]. I can also put limitations on where connections made with this key can come from, and on what they can do when connected. Anyway, I generate the key I will use on thishost (as thisuser):
$ ssh-keygen -t rsa -b 2048 -f /home/thisuser/cron/thishost-rsync-key 
Generating public/private rsa key pair. 
Enter passphrase (empty for no passphrase): [press enter here] 
Enter same passphrase again: [press enter here] 
Your identification has been saved in /home/thisuser/cron/thishost-rsync-key. 
Your public key has been saved in /home/thisuser/cron/thishost-rsync-key.pub. 
The key fingerprint is: 
2e:28:d9:ec:85:21:e7:ff:73:df:2e:07:78:f0:d0:a0 thisuser@thishost 
and now we have a key with no password in the two files mentioned above [1]. Make sure that no other unauthorized user can read the private key file (the one without the '.pub' extension).
This key serves no purpose until we put the public portion into the 'authorized_keys' file [2] on remotehost, specifically the one for remoteuser:
/home/remoteuser/.ssh/authorized_keys 
I use scp to get the file over to remotehost:
$ scp /home/thisuser/cron/thishost-rsync-key.pub remoteuser@remotehost:/home/remoteuser/ 
and then I can prepare things on remotehost.
Configuring remotehost

I 'ssh' over to remotehost:
$ ssh remoteuser@remotehost
remoteuser@remotehost's password: [type correct password here]
$ echo I am now $USER at $HOSTNAME
I am now remoteuser at remotehost
to do some work.
I need to make sure I have the directory and files I need to authorize connections with this key [3]:
$ if [ ! -d .ssh ]; then mkdir .ssh ; chmod 700 .ssh ; fi 
$ mv thishost-rsync-key.pub .ssh/ 
$ cd .ssh/ 
$ if [ ! -f authorized_keys ]; then touch authorized_keys ; chmod 600 authorized_keys ; fi 
$ cat thishost-rsync-key.pub >> authorized_keys 
Now the key can be used to make connections to this host, but these connections can be from anywhere (that the ssh daemon on remotehost allows connections from) and they can do anything (that remoteuser can do), and I don't want that. I edit the 'authorized_keys' file (with vi) and modify the line with 'thishost-rsync-key.pub' information on it. I will only be adding a few things in front of what is already there, changing the line from this:
ssh-dss AAAAB3NzaC1kc3MAAAEBAKYJenaYvMG3nHwWxKwlWLjHb77CT2hXwmC8Ap+fG8wjlaY/9t4u
A+2qx9JNorgdrWKhHSKHokFFlWRj+qk3q+lGHS+hsXuvta44W0yD0y0sW62wrEVegz+JVmntxeYc0nDz
5tVGfZe6ydlgomzj1bhfdpYe+BAwop8L+EMqKLS4iSacNjoPlHsmqHMnbibn3tBqJEq2QJjEPaiYj1iP
5IaCuYBhuTKQGa+oyH3mXEif5CKdsIKBj46B0tCy0/GC7oWcUN92QdLrUyTeRJZsTWsxKpRbMliD2pBh
4oyX/aXEf8+HZBrO5vQjDBCfTFQA+35Xrd3eTVEjkGkncI0SAeUAAAAVAMZSASmQ9Pi38mdm6oiVXD55
Kk2rAAABAE/bA402VuCsOLg9YS0NKxugT+o4UuIjyl6b2/cMmBVWO39lWAjcsKK/zEdJbrOdt/sKsxIK
1/ZIvtl92DLlMhci5c4tBjCODey4yjLhApjWgvX9D5OPp89qhah4zu509uNX7uH58Zw/+m6ZOLHN28mV
5KLUl7FTL2KZ583KrcWkUA0Id4ptUa9CAkcqn/gWkHMptgVwaZKlqZ+QtEa0V2IwUDWS097p3SlLvozw
46+ucWxwTJttCHLzUmNN7w1cIv0w/OHh5IGh+wWjV9pbO0VT3/r2jxkzqksKOYAb5CYzSNRyEwp+NIKr
Y+aJz7myu4Unn9de4cYsuXoAB6FQ5I8AAAEBAJSmDndXJCm7G66qdu3ElsLT0Jlz/es9F27r+xrg5pZ5
GjfBCRvHNo2DF4YW9MKdUQiv+ILMY8OISduTeu32nyA7dwx7z5M8b+DtasRAa1U03EfpvRQps6ovu79m
bt1OE8LS9ql8trx8qyIpYmJxmzIdBQ+kzkY+9ZlaXsaU0Ssuda7xPrX4405CbnKcpvM6q6okMP86Ejjn
75Cfzhv65hJkCjbiF7FZxosCRIuYbhEEKu2Z9Dgh+ZbsZ+9FETZVzKBs4fySA6dIw6zmGINd+KY6umMW
yJNej2Sia70fu3XLHj2yBgN5cy8arlZ80q1Mcy763RjYGkR/FkLJ611HWIA= thisuser@thishost
to this [4]:
from="10.1.1.1",command="/home/remoteuser/cron/validate-rsync" ssh-dss AAAAB3Nza
C1kc3MAAAEBAKYJenaYvMG3nHwWxKwlWLjHb77CT2hXwmC8Ap+fG8wjlaY/9t4uA+2qx9JNorgdrWKhH
SKHokFFlWRj+qk3q+lGHS+hsXuvta44W0yD0y0sW62wrEVegz+JVmntxeYc0nDz5tVGfZe6ydlgomzj1
bhfdpYe+BAwop8L+EMqKLS4iSacNjoPlHsmqHMnbibn3tBqJEq2QJjEPaiYj1iP5IaCuYBhuTKQGa+oy
H3mXEif5CKdsIKBj46B0tCy0/GC7oWcUN92QdLrUyTeRJZsTWsxKpRbMliD2pBh4oyX/aXEf8+HZBrO5
vQjDBCfTFQA+35Xrd3eTVEjkGkncI0SAeUAAAAVAMZSASmQ9Pi38mdm6oiVXD55Kk2rAAABAE/bA402V
uCsOLg9YS0NKxugT+o4UuIjyl6b2/cMmBVWO39lWAjcsKK/zEdJbrOdt/sKsxIK1/ZIvtl92DLlMhci5
c4tBjCODey4yjLhApjWgvX9D5OPp89qhah4zu509uNX7uH58Zw/+m6ZOLHN28mV5KLUl7FTL2KZ583Kr
cWkUA0Id4ptUa9CAkcqn/gWkHMptgVwaZKlqZ+QtEa0V2IwUDWS097p3SlLvozw46+ucWxwTJttCHLzU
mNN7w1cIv0w/OHh5IGh+wWjV9pbO0VT3/r2jxkzqksKOYAb5CYzSNRyEwp+NIKrY+aJz7myu4Unn9de4
cYsuXoAB6FQ5I8AAAEBAJSmDndXJCm7G66qdu3ElsLT0Jlz/es9F27r+xrg5pZ5GjfBCRvHNo2DF4YW9
MKdUQiv+ILMY8OISduTeu32nyA7dwx7z5M8b+DtasRAa1U03EfpvRQps6ovu79mbt1OE8LS9ql8trx8q
yIpYmJxmzIdBQ+kzkY+9ZlaXsaU0Ssuda7xPrX4405CbnKcpvM6q6okMP86Ejjn75Cfzhv65hJkCjbiF
7FZxosCRIuYbhEEKu2Z9Dgh+ZbsZ+9FETZVzKBs4fySA6dIw6zmGINd+KY6umMWyJNej2Sia70fu3XLH
j2yBgN5cy8arlZ80q1Mcy763RjYGkR/FkLJ611HWIA= thisuser@thishost
where "10.1.1.1" is the IP (version 4 [5]) address of thishost, and "/home/remoteuser/cron/validate-rsync" (which is just one of a few options [6], including customization [7] to enhance security) is a script that looks something like this :
#!/bin/sh 

case "$SSH_ORIGINAL_COMMAND" in 
*\&*) 
echo "Rejected" 
;; 
*\(*) 
echo "Rejected" 
;; 
*\{*) 
echo "Rejected" 
;; 
*\;*) 
echo "Rejected" 
;; 
*\<*) 
echo "Rejected" 
;; 
*\`*) 
echo "Rejected" 
;; 
*\|*) 
echo "Rejected" 
;; 
rsync\ --server*) 
$SSH_ORIGINAL_COMMAND 
;; 
*) 
echo "Rejected" 
;; 
esac 
If thishost has a variable address, or shares its address (via NAT or something similar) with hosts you do not trust, omit the 'from="10.1.1.1",' part of the line (including the comma), but leave the 'command' portion. This way, only the 'rsync' will be possible from connections using this key. Make certain that the 'validate-rsync' script is executable by remoteuser on remotehost and test it.
PLEASE NOTE: The private key, though now somewhat limited in what it can do (and hopefully where it can be done from), allows the possessor to copy any file from remotehost that remoteuser has access to. This is dangerous, and I should take whatever precautions I deem necessary to maintain the security and secrecy of this key. Some possibilities would be ensuring proper file permissions are assigned, consider using a key caching daemon, and consider if I really need this process automated verses the risk.
ALSO NOTE: Another security detail to consider is the SSH daemon configuration on remotehost. This example focuses on a user (remoteuser) who is not root. I recommend not using root as the remote user becauseroot has access to every file on remotehost. That capability alone is very dangerous, and the penalties for a mistake or misconfiguration can be far steeper than those for a 'normal' user. If you do not use root as your remote user (ever), and you make security decisions for remotehost, I recommend either:
PermitRootLogin no 
or:
PermitRootLogin forced-commands-only 
be included in the '/etc/ssh/sshd_config' file on remotehost. These are global settings, not just related to this connection, so be sure you do not need the capability these configuration options prohibit. [8].
The 'AllowUsers', 'AllowGroups', 'DenyUsers', and 'DenyGroups' key words can be used to restrict SSH access to particular users and groups. They are documented in the man page for "sshd_config", but I will mention that they all can use '*' and '?' as wildcards to allow and deny access to users and groups that match patterns. 'AllowUsers' and 'DenyUsers' can also restrict by host when the pattern is in USER@HOST form.
Troubleshooting

Now that I have the key with no password in place and configured, I need to test it out before putting it in a cron job (which has its own small set of baggage). I exit from the ssh session to remotehost and try [9]:
$ rsync -avz -e "ssh -i /home/thisuser/cron/thishost-rsync-key" remoteuser@remotehost:/remote/dir /this/dir/
If this doesn't work, I will take off the "command" restriction on the key and try again. If it asks for a password, I will check permissions on the private key file (on thishost, should be 600), on 'authorized_keys' and (onremotehost, should be 600), on the '~/.ssh/' directory (on both hosts, should be 700), and on the home directory ('~/') itself (on both hosts, should not be writeable by anyone but the user). If some cryptic 'rsync' protocol error occurs mentioning the 'validate-rsync' script, I will make sure the permissions on 'validate-rsync' (on remotehost, may be 755 if every remotehost user is trusted) allow remoteuser to read and execute it.
If things still aren't working out, some useful information may be found in log files. Log files usually found in the /var/log/ directory on most linux hosts, and in the /var/log/secure log file on Red Hat-ish linux hosts. The most useful logfiles in this instance will be found on remotehost, but localhost may provide some client side information in its logs [10] . If you can't get to the logs, or are just impatient, you can tell the 'ssh' executable to provide some logging with the 'verbose' commands: '-v', '-vv', '-vvv'. The more v's, the more verbose the output. One is in the command above, but the one below should provide much more output:
$ rsync -avvvz -e "ssh -i /home/thisuser/cron/thishost-rsync-key" remoteuser@remotehost:/remote/dir /this/dir/ 
Hopefully, it will always just work flawlessly so I never have to extend the troubleshooting information listed here [11] .
Cron Job Setup

The last step is the cron script. I use something like this:
#!/bin/sh 

RSYNC=/usr/bin/rsync 
SSH=/usr/bin/ssh 
KEY=/home/thisuser/cron/thishost-rsync-key 
RUSER=remoteuser 
RHOST=remotehost 
RPATH=/remote/dir 
LPATH=/this/dir/ 

$RSYNC -az -e "$SSH -i $KEY" $RUSER@$RHOST:$RPATH $LPATH 
because it is easy to modify the bits and pieces of the command line for different hosts and paths. I will usually call it something like 'rsync-remotehost-backups' if it contains backups. I test the script too, just in case I carefully inserted an error somewhere.
When I get the script running successfully, I use 'crontab -e' to insert a line for this new cron job:
0 5 * * * /home/thisuser/cron/rsync-remotehost-backups 
for a daily 5 AM sync, or:
0 5 * * 5 /home/thisuser/cron/rsync-remotehost-backups 
for a weekly (5 AM on Fridays). Monthly and yearly ones are rarer for me, so look at "man crontab" or here for advice on those.


Alright! Except for the everyday "keeping up with patches" thing, the insidious "hidden configuration flaws" part, and the unforgettable "total failure of human logic" set of problems, my work here is done. Enjoy!
Read more...

qnap rsync Segmentation fault daemon

  • Published in Qnap
  • April 19, 2013

qnap rsync segmentation fault daemon

 

原因 不支持 daemon  转换用 shell

 

rsync 两种方式 1 daemon  2 shell

 

rsync -avz -e ssh remoteuser@remotehost:/remote/dir /this/dir/ 

Read more...

WINDOWS 7 手动删除用户配置文件后,只能使用临时配置文件的问题

在XP时代,如果将用户的配置文件删除了,用户在登录就会自动重新创建一个配置文件

但在WINDOWS 7不行,删除用户配置文件后,不会自动创建用户的配置文件,下次登录会一直使用临时配置文件

 

原因:

如果使用命令提示符或 Windows 资源管理器手动删除用户配置文件,则可能出现此问题。手动删除的配置文件不会删除注册表中配置文件列表中的安全标识符 (SID)。

警告:Microsoft 建议不要将此方法作为删除计算机中用户配置文件的标准方法。记录和支持的方法是使用系统属性中“高级系统设置”的“用户配置文件”设置。对于应用程序来说,使用“DeleteProfile”API 即可提供此功能。

如果存在 SID,则 Windows 将通过使用指向到不存在的路径 ProfileImagePath 加载配置文件。因此,无法加载该配置文件。

 

给出了解决办法:

1,下载微软提供的修复工具 下载   运行修复

或者

1,在系统属性中找到要删除的用户,删除用户配置文件(如果存在)

2,HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

删除相应的 SID,然后单击“删除”

 

微软官方KB

http://support.microsoft.com/kb/947215/zh-cn

Read more...
Subscribe to this RSS feed