[ckan-dev] Questions regarding CKAN administration

[David Read]

2011/8/18 Ondřej Vadinský <ondrej.vadinsky at vse.cz>:
> David Read wrote:
>> > I am to upgrade CKAN to newest stable, seems to be 1.4.2 righ now. There is currently installed 1.3.2 version, should I expect some troubles regarding
>> > this upgrade?
>>
>> Perhaps @James or @Rufus could help you with this? The CKAN version
>> also affects the nederland ckan site, so this should be done
>> carefully, especially as the debian packaging system is new.
>
> Yes I know about the nederland site, could the nederland's admin contact me about this, or does someone know his adress? I would also appreciate any
> help from James or Rufus. I noticed that the package name changed from ckan to ckan-std and it does not seem to have some debians alternative to
> replaces flag. So I guess I have to remove the ckan package and then install the ckan-std spackage. This should keep the configuration right? Otherwise
> it should just follow the upgrade documentation.

@James is responsible for debian packaging, so I suggest you work with
him directly on this in this case, since there have been various
changes since those were installed.

>> > Connected to this I want to do system update, as there are out-of-date packages. Can this cause troubles? As this should upgrade kernel
>> > too, reboot is required, can I get acces to virtual server management, in case I need to see the server console?
>> > Is there some special time in which shoul I do the upgrade?
>>
>> I've done some updates. Perhaps @Nils could take care of any necessary
>> kernel updates / reboot?
>
> William Waites wrote:
>> It is, as far as I know, impossible to upgrade the kernel on an AWS
>> instance short of rebuilding it completely from a different image.
>
> Thanx for the update. I will keep the machine up-to-date. I don't like the idea of running the old kernel with known vulnerabilities though. But I do not
> understand the AWS so I do not know what the complete rebuild involves. If it is too much pain, I guess we shall let it be for now, but we should at least
> create some time cyklus in which we will update the kernel.
>
>>> We provide a shared user account for convenience of all users of this
>>> machine, so you're right that it's best not to customise the .bashrc.
>>
>> It seems to me this is a policy most pessimal. Customisations to get
>> nice working environments will likely be the most pleasant way this
>> will bite.
>
> Yes I agree. Therefor I propose to create separete acconts for the users, which would also help me to get a better idea of who works with the server and
> it would help us to know who and when changes what, so we can contact the right people in case of questions or possible troubles. What do you think?

This is up to @Nils.

> As a colleague noticed, the czech CKAN was down for some time, so I ask, is there a way how to motor such events? And which processes should be
> monitored actually?

We monitor our sites with Nagios, but it is currently password
protected. @Nils what is the policy on this - can we provide Ondrej
access or can it simply be public?

David

> Thank you,
> Ondřej Vadinský
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>