Martin Gottlieb schrieb:
> I think you're on the right track. The thing is, the login screen
> doesn't give me an option as to what sitegroup
> I'm logging into like Aegir did. Where is it determined what sitegroup
> I am logging into ? Do I need to set up a
> separate vhost for each sitegroup ?
>
It's determined by the host. So if www.mysite.com/prefix is listed as
SG3 in the host db table, www.mysite.com/prefix/midcom-login- wants a
user from SG3. You don't need separate apache vhosts, just separate
midgard hosts (i.e. entries in the host table) for each sitegroup, but
these should exist anyways.
If you have a host which belongs to SG0, you can also log in as the
admin user and access all the content of all the other sitegroups from
there via asgard, but it'll be all mushed together in the same
navigation tree, so it's going to be less usable than aegir.
Bye,
Andreas
> Thanks.
>
> Martin
>
> Andreas Flack wrote:
>> Martin Gottlieb schrieb:
>>
>>> Thanks Piotr. I now have the midcom admin tool working ! I think I'm
>>> going to skip trying to get midgard-php compiled
>>> from source and just eliminate any calls to the deprecated API, so I
>>> won't have to worry about compatibility. There are only
>>> a couple of calls that I can think of so it shouldn't be too much of a
>>> problem.
>>>
>>> Just a quick question about the midcom admin tool and I think I'll be
>>> good to go: I am not able to log in using the admin
>>> account. Currently, the password is stored in the database in clear
>>> text ( **ThePassword). I tried copying the encrypted
>>> password from a login that does work but still no luck. I keep getting
>>> "Username or password was invalid".
>>>
>>> Any ideas why this login does not work ?
>>>
>> Could it be that you're trying to log into another sitegroup? AFAIR in
>> the old admin interfaces you could use an SG0 account to log into the
>> admin interface of another sitegroup, but in midcom, this doesn't work.
>> So if you have your midcom-login- under a host in sitegroup 1, the
>> standard 'admin' user with ID 1 that midgard creates on installation
>> won't be able to access it (BTW, I'm wondering why this is like that.
>> The same user could log into asgard in SG0 and make modifiactions from
>> there, so this wouldn't even give him more privileges).
>>
>>
>> Bye,
>>
>> Andreas
>>
>>
>>
>>> Thanks again for all of your help !
>>>
>>> Martin
>>>
>>>
>>> Piotr Pokora wrote:
>>>
>>>> Martin Gottlieb writes:
>>>>
>>>> Hi!
>>>>
>>>>
>>>>
>>>>>>> PHP Fatal error: Call to undefined function mgd_get_host() ...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> All legacy functions are deprecated since 1.8 at least IIRC.
>>>>>>
>>>>>>
>>>>>>
>>>>> Thanks. I was afraid that was the case.
>>>>>
>>>>> Are there equivalent calls in the new API? If it ends up being only a
>>>>> few calls that I need, it might be
>>>>> worth writing a wrapper that maps them into the new API.
>>>>>
>>>>>
>>>> function mgd_get_host($id)
>>>> {
>>>> $host = null;
>>>> try
>>>> {
>>>> $host = new midgard_host($id);
>>>> }
>>>> catch (midgard_error_exception $e) {
>>>>
>>>> }
>>>>
>>>> return $host;
>>>> }
>>>>
>>>> You can provide similar for page, style , etc.
>>>>
>>>>
>>>>
>>>>> Also, without Aegir or Spider, is midcom the recommended (only) admin
>>>>> tool for managing midgard sites in 8.09 ?
>>>>>
>>>>>
>>>> Yep, MidCOM is the only one recommended.
>>>>
>>>>
>>>>
>>>>> I attempted to get that working also but am getting 404s when trying to
>>>>> access "/midcom-login-". There is no host
>>>>> record with a prefix set to "/midcom-login-". Should there be or is
>>>>> this handled a different way ?
>>>>>
>>>>>
>>>> You can try datagard.
>>>>
>>>> `datagard -c myconfig -a vhost`
>>>>
>>>> Do not forget to edit/create 'myconfig' file.
>>>> http://www.midgard-project.org/documentation/unified-configuration/
>>>>
>>>>
>>>>
>>>>> I attempted this and got loads of errors on the "make " step.
>>>>>
>>>>>
>>>> Make sure you have all devel package installed. At least: glib-devel ,
>>>> php-devel.
>>>>
>>>>
>>>>
>>>>> This
>>>>> combined with the fact that it will not
>>>>> be supported leads me to the questions I asked above about mapping the
>>>>> old API calls into the new.
>>>>> It's either that or drop back to 1.8.9.
>>>>>
>>>>>
>>>> No one recommends going back to 1.8.
>>>> I would do things like this:
>>>>
>>>> 1. Build midgard-php with legacy API.
>>>> Bother us in case of any problems.
>>>>
>>>> 2. Keep exisiting sites.
>>>>
>>>> 3. Start transition to new API.
>>>>
>>>> Piotras
>>>> _______________________________________________
>>>> user mailing list
>>>> [email protected]
>>>> http://lists.midgard-project.org/mailman/listinfo/user
>>>>
>>>>
>>> _______________________________________________
>>> user mailing list
>>> [email protected]
>>> http://lists.midgard-project.org/mailman/listinfo/user
>>>
>> _______________________________________________
>> user mailing list
>> [email protected]
>> http://lists.midgard-project.org/mailman/listinfo/user
>>
> _______________________________________________
> user mailing list
> [email protected]
> http://lists.midgard-project.org/mailman/listinfo/user
_______________________________________________
user mailing list
[email protected]
http://lists.midgard-project.org/mailman/listinfo/user
