- First install theme on portal using Theme and Skins portlet
- Then i did full export of the portal using xmlaccess
- Then i did find the theme to which i want to assign unique name and copied into a different xml like this
<?xml version="1.0" encoding="UTF-8"?>
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" build="wp6103_201_01" type="update"
version="6.1.0.3" xsi:noNamespaceSchemaLocation="PortalConfig_6.1.0.2.xsd">
<portal action="locate">
<theme action="update" active="true" default="false" defaultskinref="K_VVILMKG10GV1F0IIS98H1C0002" domain="rel"
objectid="J_VVILMKG10GV1F0IIS98H1C0004" resourceroot="empty"
uniquename="com.webspherenotes.emptytheme" >
<localedata locale="en">
<title>Empty</title>
</localedata>
</theme>
</portal>
</request>
In this theme element i did add uniquename attribute with value equal to the unique name that i want to assign - Import this xmlaccess script into the portal
Showing posts with label XMLAccess. Show all posts
Showing posts with label XMLAccess. Show all posts
Assigning unique name to theme
WebSphere Portal SPI allows you to assign a theme to a page or skin to portlet window pro-grammatically, but if you want to do that then you will have to assign unique name to theme but i could not find any way to assign unique name to theme using Admin console so this is what i did
Assigning unique name to skin
WebSphere Portal SPI allows you to assign a theme to a page or skin to portlet window pro-grammatically, but if you want to do that then you will have to assign unique name to skin but i could not find any way to assign unique name to skin using Admin console so this is what i did
- First install skin on portal using Theme and Skins portlet
- Then i did full export of the portal using xmlaccess
- Then i did find the skin to which i want to assign unique name and copied into a different xml like this
<?xml version="1.0" encoding="UTF-8"?>
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" build="wp6103_201_01"
type="update" version="6.1.0.3" xsi:noNamespaceSchemaLocation="PortalConfig_6.1.0.2.xsd">
<portal action="locate">
<skin action="update" active="true" default="false" domain="rel" objectid="K_VVILMKG10GV1F0IIS98H1C0002"
resourceroot="empty" type="default"
uniquename="com.webspherenotes.emptyskin" >
<localedata locale="en">
<title>Empty</title>
</localedata>
</skin>
</portal>
</request>
In this skin element i did add uniquename attribute with value equal to the unique name that i want to assign - Import this xmlaccess script into the portal
Schema file for the xmlaccess
IBM WebSphere POrtal Server Infocenter or the other documentation from IBM does not have much information about the xmlaccess and what all elements it has, what are the attributes that they support and what should be there value.
I always thought that if i could somehow look into the .xsd file for xmlaccess then it would be a big help but did not know where to find it. TOday i realized that those files are in the
I wanted to find out more information about the PortalCOnfig_1.4.xsd, which is the default version for WPS 6.1.5 so when i opened it in Text Editor, this is what i found. As you can see it has lot of useful information
I always thought that if i could somehow look into the .xsd file for xmlaccess then it would be a big help but did not know where to find it. TOday i realized that those files are in the
WebSphere/wp_profile/installedApps/DefaultNode/wps.ear/wps.war/dtd/. It seems that it has the latest .xsd as well as all the .xsd for older version of portals server. This is how my dtd folder looks like
I wanted to find out more information about the PortalCOnfig_1.4.xsd, which is the default version for WPS 6.1.5 so when i opened it in Text Editor, this is what i found. As you can see it has lot of useful information
Identify the function of elements in the XMLAccess script XML Scheme
Take a look at XML Configuration Interface for details.
Exporting Release
If you want to move a complete configuration from a test to a production server by using the portal Release Builder tool then you should use ExportRelease.xml.
As you can notice request has domain='rel' attribute which indicates that only shared resources(From release domain) should be exported. Private resources are in customization domain they wont get exported
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd" type="export"
domain="rel">
<portal action="export" />
</request>
As you can notice request has domain='rel' attribute which indicates that only shared resources(From release domain) should be exported. Private resources are in customization domain they wont get exported
Create XMLAccess scripts for deploying, updating, deleting, and performing routine maintenance on portal resources
In addition to importing the xmlaccess export of one portal to another, you can also use it for CRUD operations
<>
<>
Create XMLAccess scripts copy individual portal resources development to integration environments
Lets say you want to move a page from your development to integration environment. I am planning to move XMLAccess Test page from my portal on VMWare to Portal on Local machine. I will have to follow these steps for that
Important Note: In order for your page import to work all the referenced resources should be present on the target server. i.e. resources with action=locate if say you dont have the portlet installed on target then it will result in error. Or say you try to import page and one of its parent is missing on the target it will fail.
When you crate new VP it wont have ibm.portal.Home page created by default so if you try to import exportpageresult.xml on that blank vp it will fail.
- Create a XMLAccess Test page like this. While doing that assign
com.wpcertification.xmlaccess.testas unique name to it. You can use this name to reference the page while exporting it. - Add two portlets Welcome WebSphere to WebSphere Portal and About WebSphere Portal to it
- Create exportpage.xml file like this in /tmp/xmlaccess folder. YOu will have to specify either the objectid which is big number like
6_H24EGKG100G350I0OR9K0000Q4this or uniqnname of the page. and value of action should be export.
<?xml version="1.0" encoding="UTF-8"?>
<request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"
type="export">
<portal action="locate">
<content-node action="export" uniquename="com.wpcertification.xmlaccess.test"/>
</portal>
</request> - Once your exportpage.xml is ready you can execute following command
./xmlaccess.sh -in /tmp/xmlaccess/exportpage.xml -out /tmp/xmlaccess/exportpageresult.xml -user wasadmin -password wasadmin -url http://localhost:10040/wps/config - If the xmlaccess is successful then it will create exportpageresult.xml document like this on your disk.
<?xml version="1.0" encoding="UTF-8"?>
<!-- IBM WebSphere Portal/6.1.0.1 build wp6101_115_01 exported on Thu Mar 19 12:44:21 EDT 2009 from spinfotech.com/127.0.0.1 -->
<!-- 1 [content-node 6_000000000000000000000000A0] -->
<!-- 2 [content-node 6_CGAH47L00G72502N5S2MAV00I3] -->
<!-- 3 [content-node 6_H24EGKG100G350I0OR9K0000Q4 uniquename=com.wpcertification.xmlaccess.test] -->
<!-- 4 [component 7_H24EGKG100G350I0OR9K0000Q2] -->
<!-- 5 [component 7_H24EGKG100G350I0OR9K0000Q6] -->
<!-- 6 [component 7_H24EGKG100G350I0OR9K0000Q7] -->
<!-- 7 [web-app 1_CGAH47L00G72502N5S2MAV0G24] -->
<!-- 8 [portlet-app 2_CGAH47L00G72502N5S2MAV0G22] -->
<!-- 9 [servlet V_CGAH47L00G72502N5S2MAV0G26] -->
<!-- 10 [portlet 3_CGAH47L00G72502N5S2MAV0G21] -->
<!-- 11 [portletinstance 5_H24EGKG100G350I0OR9K0000Q3] -->
<!-- 12 [component 7_H24EGKG100G350I0OR9K0000Q1] -->
<!-- 13 [component 7_H24EGKG100G350I0OR9K000064] -->
<!-- 14 [web-app 1_CGAH47L00G72502N5S2MAV0012] -->
<!-- 15 [portlet-app 2_CGAH47L00G72502N5S2MAV0016] -->
<!-- 16 [servlet V_CGAH47L00G72502N5S2MAV0011] -->
<!-- 17 [portlet 3_CGAH47L00G72502N5S2MAV0015] -->
<!-- 18 [portletinstance 5_H24EGKG100G350I0OR9K000060] -->
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" build="wp6101_115_01" type="update" version="6.1.0.1" xsi:noNamespaceSchemaLocation="PortalConfig_6.1.0.xsd">
<portal action="locate">
<web-app action="locate" domain="rel" objectid="1_CGAH47L00G72502N5S2MAV0G24" uid="BlurbPortlet.3088d83ae7690017105c9e64cce97eb8">
<servlet action="locate" domain="rel" name="Welcome to WebSphere Portal.$appuid.BlurbPortlet.3088d83ae7690017105c9e64cce97eb8.1" objectid="V_CGAH47L00G72502N5S2MAV0G26"/>
<portlet-app action="locate" domain="rel" name="Information Portlet Application" objectid="2_CGAH47L00G72502N5S2MAV0G22" uid="BlurbPortlet.3088d83ae7690017105c9e64cce97eb8.1">
<portlet action="locate" domain="rel" name="Welcome to WebSphere Portal" objectid="3_CGAH47L00G72502N5S2MAV0G21" uniquename="wps.p.Welcome To WebSphere Portal"/>
</portlet-app>
</web-app>
<web-app action="locate" domain="rel" objectid="1_CGAH47L00G72502N5S2MAV0012" uid="com.ibm.wps.portlets.welcome">
<servlet action="locate" domain="rel" name="Welcome Portlet.$appuid.com.ibm.wps.portlets.welcome.1" objectid="V_CGAH47L00G72502N5S2MAV0011"/>
<portlet-app action="locate" domain="rel" name="Welcome" objectid="2_CGAH47L00G72502N5S2MAV0016" uid="com.ibm.wps.portlets.welcome.1">
<portlet action="locate" domain="rel" name="Welcome Portlet" objectid="3_CGAH47L00G72502N5S2MAV0015" uniquename="wps.p.Welcome"/>
</portlet-app>
</web-app>
<content-node action="locate" domain="rel" objectid="6_000000000000000000000000A0" uniquename="wps.content.root"/>
<content-node action="locate" domain="rel" uniquename="ibm.portal.admin.vp.Home"/>
<content-node action="update" active="true" allportletsallowed="true" content-parentref="6_CGAH47L00G72502N5S2MAV00I3" create-type="explicit" domain="rel" objectid="6_H24EGKG100G350I0OR9K0000Q4" ordinal="200" type="page" uniquename="com.wpcertification.xmlaccess.test">
<supported-markup markup="html" update="set"/>
<localedata locale="en">
<title>XMLAccess Test page</title>
</localedata>
<parameter name="com.ibm.portal.IgnoreAccessControlInCaches" type="string" update="set"><![CDATA[false]]></parameter>
<parameter name="com.ibm.portal.bookmarkable" type="string" update="set"><![CDATA[Yes]]></parameter>
<parameter name="com.ibm.portal.remote-cache-expiry" type="string" update="set"><![CDATA[0]]></parameter>
<parameter name="com.ibm.portal.remote-cache-scope" type="string" update="set"><![CDATA[NON-SHARED]]></parameter>
<access-control externalized="false" owner="uid=wasadmin,o=defaultwimfilebasedrealm" private="false"/>
<component action="update" active="true" deletable="undefined" domain="rel" modifiable="undefined" objectid="7_H24EGKG100G350I0OR9K0000Q2" ordinal="100" orientation="H" skinref="undefined" type="container" width="undefined">
<component action="update" active="true" deletable="undefined" domain="rel" modifiable="undefined" objectid="7_H24EGKG100G350I0OR9K0000Q6" ordinal="100" orientation="V" skinref="undefined" type="container" width="undefined">
<component action="update" active="true" deletable="undefined" domain="rel" modifiable="undefined" objectid="7_H24EGKG100G350I0OR9K0000Q7" ordinal="100" skinref="undefined" type="control" width="undefined">
<portletinstance action="update" domain="rel" objectid="5_H24EGKG100G350I0OR9K0000Q3" portletref="3_CGAH47L00G72502N5S2MAV0G21" shareref="5_H24EGKG100G350I0OR9K0000Q3"/>
</component>
</component>
<component action="update" active="true" deletable="undefined" domain="rel" modifiable="undefined" objectid="7_H24EGKG100G350I0OR9K0000Q1" ordinal="200" orientation="V" skinref="undefined" type="container" width="undefined">
<component action="update" active="true" deletable="undefined" domain="rel" modifiable="undefined" objectid="7_H24EGKG100G350I0OR9K000064" ordinal="100" skinref="undefined" type="control" width="undefined">
<portletinstance action="update" domain="rel" objectid="5_H24EGKG100G350I0OR9K000060" portletref="3_CGAH47L00G72502N5S2MAV0015" shareref="5_H24EGKG100G350I0OR9K000060"/>
</component>
</component>
</component>
</content-node>
</portal>
<status element="all" result="ok"/>
</request>
The export script has lot of information- web-app: There are two web-app elements at the start that represent two portlets included on your page. The value of action attribute is locate for the web-app as they are just for locating references
- parent content-node: First two content nodes are used to locate the parent of the page from content root. Both those elements have action equal to locate, so they are used to find the objectid of the page.
- Page content-node: The page content node is the third node with action equal to update thats the page definition for xmlaccess. It has child elements indicating page level parameters, access control,.. Then it has one component node which is the horizontal container on the page. The Horizontal container has one child vertical container that has one child for the portlet instance that is used to indicate the actual portlet instance on the page. Since we have two portlet instances on the page we have two porteltinstance nodes. If your portlet window has any preferences attached to it then those preferences would be included here.
When you look at the file, you notice that it includes not only the page itself but also other configuration elements that are referred to by the page, for example the portlet that is placed on the page. These other elements have a locate action. The export does not include their full configuration data, but just enough information to look them up in the portal, assuming they already exist. Note how the configuration of the page makes references to the objectid attributes of other resources, for example in the portletref attribute of the portletinstance elements.
All those references are described by object IDs. Therefore, if the object IDs are correct, the referenced resources could be looked up in the portal even if they were not included in the export. Locating resources before they are referenced is only necessary if you do not know their actual object IDs, so the resources need to be found by some other identifying attribute (see the XML reference documentation). That way, for example a portlet can be identified by its name and by the uid attributes of its parents, and the referencing will still work, even if the object ID is not available for looking up the portlet. - Since our page export is ready we will import it on my remote machine using this xmlaccess command
./xmlaccess.sh -in /tmp/xmlaccess/exportpageresult.xml -out /tmp/xmlaccess/importpageresult.xml -user wasadmin -password wasadmin -url http://192.168.2.105:10040/wps/config - Once the xlmaccess command is executed check importpageresult.xml to see if the result is success.
Important Note: In order for your page import to work all the referenced resources should be present on the target server. i.e. resources with action=locate if say you dont have the portlet installed on target then it will result in error. Or say you try to import page and one of its parent is missing on the target it will fail.
When you crate new VP it wont have ibm.portal.Home page created by default so if you try to import exportpageresult.xml on that blank vp it will fail.
XMLAccess askForCredential parameter
Starting from WPS 6.1 portal has introduced
This might be good option if you have build script that executes xmlaccess and you dont want to save your user name and password in the build script. Other advantage of doing that is you dont have to pass the password using visible format on the command line. Also if some one looks at the process view on the machine at the same time when your executing xmlaccess he wont see your password.
askForCredential parameter for xmlaccess.sh/.bat. You can pass this parameter to xmlaccess and skip passing username and password when you do that xmlaccess script will prompt you for usernmae and password at the runtime.
This might be good option if you have build script that executes xmlaccess and you dont want to save your user name and password in the build script. Other advantage of doing that is you dont have to pass the password using visible format on the command line. Also if some one looks at the process view on the machine at the same time when your executing xmlaccess he wont see your password.
Export and import page hierarchy using Administration Portlets
In addition to the command line interface, Portal also provides couple of portlets that you can use to work with the xmlaccess.
- Manage Pages Portlet: You can use the Manage pages portlet to export either a page or page hierarchy. In the Manage pages portlet click on Export button next to the portlet or label that you want to export. It will ask you if you want to export only that page or the hierarchy below it. Select appropriate option and it will ask you to download the result xmlaccess
- You can use Import XML portlet to execute an xmlaccess script on the target server. Just go to the Import XML portlet select the xmlaccess script that you want to execute.It will display the result on the next page. It does not allow to download the result xml file.
Taking closer look at xmlaccess request
Top element of xmlaccess script file is always <request>. The request element has type attribute that determines what type of request is it. Type attribute supports three values
The <request> top element can have either portal or status as child element or in somecases both of them
This is sample result.xml file with status equal to ok that means the request was executed successfully.
- export: when you set type equal to export that means you want to export full or part of the portal configuration. The child elements of request element would be used to indicate what all elements you wan to export. This request will not change any configuration on the portal where it is executed.
- update: when you set type equal to update that means you want to update the configuration of the portal where your executing this request. Child elements of request element indicate the exact update that you want to make
- export-orphaned-data:An export-orphaned-data request exports the complete portal configuration into XML, including orphaned data. It results in a response file. This type of request is used exclusively for removing orphaned data using SLCCheckerTool
//Export Request - Sample for exporting full portal configuration
<?xml version="1.0" encoding="UTF-8"?>
<request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"
type="export"
export-users="false">
<portal action="export"/>
</request>
//Export orphaned data request- Sample for exporting full portal including the orphaned data
<request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"
type="export-orphaned-data"
export-users="false">
<portal action="export"/>
</request>
//Import request - Sample for creating URL mapping
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"
type="update"
create-oids="true">
<portal action="locate">
<content-node action="locate" uniquename="ibm.portal.SamplePage" objectid="SamplePage"/>
<url-mapping-context action="update" label="samples">
<additional-label>examples</additional-label>
<portal-url resourceref="SamplePage" locale="en"/>
</url-mapping-context>
</portal>
</request>
The <request> top element can have either portal or status as child element or in somecases both of them
- portal: This is the main element in the request. It represents the portal
- status: When xmlaccess generates response it will add status element as child of request element to indicate what status of the request.
This is sample result.xml file with status equal to ok that means the request was executed successfully.
<request build="wp6101_115_01" type="update" version="6.1.0.1" xsi:noNamespaceSchemaLocation="PortalConfig_6.1.0.xsd">
<status element="all" result="ok"/>
</request>
XMLAccess Script syntax
The way XMLAccess scripts work is you create XML input file that defines what you want to do and pass it to the xmlaccess client side program. The xmlaccess client will communicate to the server over HTTP or Secure HTTP using SSL and return the response by generating result.xml file on the local disk. You can check this file to find out if the xmlaccess script was executed successfully or not.
You can execute xmlaccess script by going to portal_server_root/bin directory and executing xmlaccess.sh/.bat file.
The basic syntax for executing XMLAccess is like this
The xmlaccess script takes additional command line parameter as well as there is an option to communicate xmlaccess script using SSL secured connection. If you want any of those options take a look at Working with XMLConfiguration Interface for details.
Important Note: The configuration URL that you use while executing xmlaccess actually points to
The common approach of using xmlaccess is that you go to target portal server and export full or part of the configuration using xmlaccess. The configuration would be exported as xmlaccess file. Once you have that file you can go to target and import that configuration on target and portal server will create those resource on the target server.
Requests to and responses from the XML configuration interface use the same XML format. An export request generates an XML response that contains all the configuration data required to re-create the exported configuration part. This means that you can export a portal configuration, save the XML output file and, without modification, send it to another portal to re-create the same configuration there.
You can execute xmlaccess script by going to portal_server_root/bin directory and executing xmlaccess.sh/.bat file.
The basic syntax for executing XMLAccess is like this
xmlaccess -user <username> -password <lpassword >
-url <configurl>
-in <input_file.xml> -out <result_file.xml>
- username: User Name of the portal security administrator
- password: Password of the portal security administrator
- configURL: Config URL that xmlaccess client should connect
- input_file.xml: Fully qualified path of the input xml file
- result_file.xml: Fully qualified path of the result xml file. XMLAccess script will generate the result file
The xmlaccess script takes additional command line parameter as well as there is an option to communicate xmlaccess script using SSL secured connection. If you want any of those options take a look at Working with XMLConfiguration Interface for details.
Important Note: The configuration URL that you use while executing xmlaccess actually points to
com.ibm.wps.command.xml.XmlCommandServlet that is wps_xml.war which is part of wps.ear
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="IBM_WPS_XML_FACADE" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>WebSphere Portal XmlAccess Facade</display-name>
<servlet>
<servlet-name>config</servlet-name>
<servlet-class>com.ibm.wps.command.xml.XmlCommandServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>config</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
The common approach of using xmlaccess is that you go to target portal server and export full or part of the configuration using xmlaccess. The configuration would be exported as xmlaccess file. Once you have that file you can go to target and import that configuration on target and portal server will create those resource on the target server.
Requests to and responses from the XML configuration interface use the same XML format. An export request generates an XML response that contains all the configuration data required to re-create the exported configuration part. This means that you can export a portal configuration, save the XML output file and, without modification, send it to another portal to re-create the same configuration there.
XMLAccess related ACLS
To be able to use the XML Configuration interface, you need two things
This means that you must be super administrator of the portal, who can perform any action.
When you execute XMLAccess script that operation would be executed in the super administrator role and no access checks would be performed to check if you have access to perform that operation.
- manager role on the XML_ACCESS virtual resource
- Security administrator role on the PORTAL virutal resource
This means that you must be super administrator of the portal, who can perform any action.
When you execute XMLAccess script that operation would be executed in the super administrator role and no access checks would be performed to check if you have access to perform that operation.
About XMLAccess Interface
The XML configuration interface provides a batch processing interface for portal configuration updates. It allows you to export an entire portal confiugration or parts of configuration to XML file. Then you can import this XML file in someother portal server to recreate configuration.
You access the XML configuration interface using a command line tool. This command line client is a small separate program that connects to the portal server using HTTP/HTTPS connection. You can use it for configuring portal remotely.
To be able to use the XML Configuration interface you need to have the manager role on the virtual resource XML_ACCESS and the security administrator role on the virtual resource PORTAL. This implies that you must be a super administrator of the portal who can perform any action. Therefore there is no further access control.
Following types of requests that can be sent to the XML Configuration interface
Requets to and response from XML configuration interface use the same XML format. An export request generates an XML response that contains all the configuration data required to re-create the exported configuration part. This means that you can export a portal configuration, save the XML output file and, without modification, send it to another portal to re-create the same configuration there.
You access the XML configuration interface using a command line tool. This command line client is a small separate program that connects to the portal server using HTTP/HTTPS connection. You can use it for configuring portal remotely.
To be able to use the XML Configuration interface you need to have the manager role on the virtual resource XML_ACCESS and the security administrator role on the virtual resource PORTAL. This implies that you must be a super administrator of the portal who can perform any action. Therefore there is no further access control.
Following types of requests that can be sent to the XML Configuration interface
- Export Request: An export request triggers the export of complete or partial portal configuration into XML. It does not modify the configuration of the portal. it results in a response file
<request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"
type="export"
export-users="false">
</request> - Update request: An update request modifies the configuration of portal according to values found in the XML script.
<request build="wp6014_010_01" type="update" version="6.0.1.4" xsi:noNamespaceSchemaLocation="PortalConfig_6.0.1_2.xsd">
// Configuration that you want to import
</request> - Export orphaned data request: It exports the complete portal configuration into XML including orphaned data.
<request build="wp6014_010_01" type="Export-orphaned-data" version="6.0.1.4" xsi:noNamespaceSchemaLocation="PortalConfig_6.0.1_2.xsd">
</request>
Requets to and response from XML configuration interface use the same XML format. An export request generates an XML response that contains all the configuration data required to re-create the exported configuration part. This means that you can export a portal configuration, save the XML output file and, without modification, send it to another portal to re-create the same configuration there.
Subscribe to:
Posts (Atom)