Portal instance hosting issues

[14年前 に Aniceto P Madrid によって更新されました。]

I want to check if the way to create and run portal instances is in this way:

1. After logging into the main portal, I created a new portal instance with it's own virtual server (fqdn)
2. I added that fqdn to /etc/hosts file
3. I opened a browser to that virtual server. No users have been added so the only available user is the default.admin user set in the portal.properties / portal-ext.properties
4. Only the default.admin has enough permissions to add roles, etc.
5. A new user must be created to delegate all administrative tasks: create and manage organizations, communities, roles and users.

Some issues arise at this moment:

If the Administrator role is assigned to a any user, he/she can deactivate or erase any user, even the default.admin user in that instance; can change the virtual server and do another things not ver portal hoster friendly.

Case the default.admin account is deactivated or erased, the portal hoster cannot log in that instance.

Which role or list of permissions is right to grant enough permissions to the portal instance administrator, but prevent him/her to manage the initial administrator account and do other less than friendly actions? If that initial user (from default.admin) is deactivated or deleted, that default.admin user is no longer valid.

How to log into a portal instance when no administrator enabled user is available?

How to erase portal instances (with all it's documents, images, etc)? I can't find where is the action to do that.

Is it possible to backup only a portal instace and restore it in another liferay server (database, documents, images, etc) ?



Thanks

[14年前 に Lisa Simpson によって更新されました。]

All VERY good questions. I'd like to know the answer as well.

[14年前 に Aniceto P Madrid によって更新されました。]

I have got a solution for the problem of log into a portal instance by browsing tables "company" and "users_".

With the first you can locate de companyId of the portal instance. With it, you can select the users in the second table for that companyId.

In my case, I was not sure which emails where available so it was easy to locate them. Besides, the password remainder question and answer are stored in plain text, so you can click in forgot password and get a new one.

If the rigth user is inactive, you can update the column active_ to 1 and then ask for password remainder.

In the case there is no email controlled by you, probably, but not yet tested, you can update the email field in the table and click in forgot password for that new updated email. You will receive in your mail box the new password.

The last case, not yet tested, is to know which user to his email, because that user must have the administrator role; otherwise, it's useless. I the role_ table you can filter by companyId and locate the Administrator role to get the roleId. The you can find in table user_roles which user has that roleId assigned. That is the user row to update it's email column.

Case after update it doesn't work, probably there is problem with caches. A server reboot will make updates work.

I hope that may help.

Aniceto

[14年前 に Lisa Simpson によって更新されました。]

I've gotten around this by creating a "virtual host" and then an org for that virtual host. Let's say that I'm hosting XYZ corp on my own personal server - Curltalk.net. I'll create the instance and the org. I'll assign the XYZ admin as an org admin and let them go from there. They never ever get access to anything outside their org. I'm not creating someone I'm hosting for as an omni-admin that way. It also locks them out of sharing content, users, etc.

[14年前 に Aniceto P Madrid によって更新されました。]

Lisa
That solution is not good if you want to leverage all the Liferay possibilites. The main is delegated administration cannot be made.

Only the portal administrator can:
- create/delete organizations,
- create/delete communities
- deactivate users
- create/edit/delete/assign regular roles
...

What I mean by portal hosting (not liferay portal server hosting) is:
- create a portal instance and assign it to a virtual host
- create a portal administrator account
- train the instance administrator (customer)
- create a customer account and assign he/she a customer role with permissions for every administrative task in the instance except those which can make the portal unusable, for instance change the virtual host
- issue to the customer an invoice every month

and...
- log in into that instance whenever I need to(for instance, to migrate it to another server)
- destroy the portal and every portal asset when required

In other words, I think in Liferay hosting as web server hosting.

Aniceto

[14年前 に Lisa Simpson によって更新されました。]

While I agree with you for larger installations, for smaller ones I still end up doing that stuff because customers would often rather throw money at at me than learn how to click through something themselves. As long as they're willing to pay for my time....