[ckan-dev] Questions regarding CKAN administration

[Ondřej Vadinský]

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.

> > 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?


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?

Thank you,
Ondřej Vadinský