First thing: I am sorry that this mail comes this late, it should have been there a week earlier.
Second: At Fosdem we sat together with a round of people, trying to identify which parts CentOS has that are facing to the community, which parts need renewing and which contents should go / has to go where.
We identified 5 parts, some of which can and will stay as they are (mostly), some which need to change. And we discussed some architectural things.
What we did not discuss was which software should be used where, although for many pieces this already has been chosen.
At the end of the mail I will talk about some pros and cons to this approach.
- Bug reporting against the CentOS components
We will continue to use mantis as our bug tracker, so there will be no change in software there, maybe an update to the newest version, if that can be done without too many issues.
- Wiki
The wiki will find it's role as being about the distribution side of things (read on for an explanation). All documentation about the project which is generated by the project and community members will go on the wiki. This means FAQs, all help material for users, Howtos and Tipps, but also QA content (see the QaTeam section) and the main Release Notes and translations. MoinMoin will be used there for the time coming.
Planning of events where CentOS will be shown will still happen on the wiki.
- Website
The website will be about the project side of things. Firstly it should be a starting point for all users - a role which it does not really play at the moment. Where to download the distribution, what is current, where to get help if you need it, pointers to things people can help with - all that should be easily found on the website.
Also on the website will be generated content for CentOS. This means the hosting of upstream documentation, automated content via RSS (so planet.centos.org shouldn't be it's own page anymore, those Feeds should be on the website), Twitter feeds and so on. No decision on whose feeds should be found on there have been made yet.
If you are looking for events, where you can talk to people who are around CentOS should also be found on the website.
Mirrors, mirror status and general infrastructure content will also be on the website.
Downloads for projects within CentOS should also be found here (like Artwork, special CD isos, or whatever you can think of a project within the CentOS eco system)
Aim is to have something which can be automatically filled in parts, and be easy to access and update in the other parts.
The website is for finished things.
- Forums
Forums at the moment are an integral part of the website. They will need to move, as we sure are moving away from the current content management system. We already know how to migrate those forums into php-bb, so we will go with that.
- Projects
People wanting to run projects or Special Interest Groups (SIGs) within CentOS need a place to develop. We have projects.centos.org for that, which has it's own wiki, bug tracker and version control system for those projects. Once things are in a releasable state, those releases should go to a part of the main web site.
projects.centos.org is for developing things.
- Glue
At the moment we have different user databases for everything except website and forums. This has to change. As far as we've found out, every piece of software we use at the moment can be coaxed to authenticate against an LDAP database. We want to order those accounts by email (make that the primary key, as it has to be unique) and try to merge them into one large database. Logging in will still be done on username / password or on the wiki with WikiName / password, where your WikiName will be one of the attributes your account has in the LDAP backend.
This has some issues: We will invariably have lots of doubled accounts, as people might have subscribed to the website with a different mail address than to the wiki. We will need to weed out spammer acocunts, something which probably will not be easy.
This is something which will still need discussion on how to do it, and especially on how to do the transition correctly, so that it does not have a large impact on users.
- Mailing lists
Last issue, as there won't be any changes there.
Pros and Cons:
- Pros
Clear division of which content will go where. This also means that a clearer presentation of content can be done on all parts, not the muddle we have there at the moment.
One user database allows all users to access parts of the CentOS infrastructure with only one account, although representations of those accounts may differ among applications, like the wiki, where the FirstnameLastname account naming still is wanted. This doesn't mean that you can automatically write on the wiki once you have an account, the procedure will mostly stay as it is at the moment.
With one user database, only one place is needed to distinguish users from bots: The place where you register your account. Another plus: the schema is extendable, should the need arise.
- Cons
Some software might need to be convinced to play well with LDAP authentication.
Links between forum posts might go away, I am not sure if there is a possibility to find out the new target of a link.
As already mentioned above: Merging the user accounts will probably be a rather largish task: Find out which accounts haven't been used for a certain time, weed out spammer's accounts out of those which have been actively used, find out which accounts belong together, retaining editing rights on the wiki, maybe moving the forum status (rookie, newbie, pro and whatever they are called) to the new forums.
We don't have a central account management solution at the moment, this also needs to be written or snarfed from somewhere, and then adapted to our needs.
Conclusion:
With the content division in mind, there now is a clearer view of what needs to go where. With a central user database, we make many things easier for users and for the people maintaining the different parts of "the CentOS web".
Now please discuss if you can live with what is written above, if you see things differently, if you have other ideas and so on. Please try to not extend what is above too much, as that already looks like a rather largish move.
Ah yes, we'd like to stay with the layout we have on wiki.centos.org throughout the whole eco system if possible. No idea if it is needed on bugs.centos.org or lists.centos.org, though.
For actual execution we will use Atrium for planning, more on how to set up your account there will come after this discussion.
Thanks for reading this far (and please trim your mails when replying only to parts of this mail!).
Ralph
On Thu, Feb 17, 2011 at 5:16 PM, Ralph Angenendt ralph.angenendt@gmail.com wrote:
- Glue
At the moment we have different user databases for everything except website and forums. This has to change. As far as we've found out, every piece of software we use at the moment can be coaxed to authenticate against an LDAP database. We want to order those accounts by email (make that the primary key, as it has to be unique) and try to merge them into one large database. Logging in will still be done on username / password or on the wiki with WikiName / password, where your WikiName will be one of the attributes your account has in the LDAP backend.
Dear Lord, yes, that makes sense.
This has some issues: We will invariably have lots of doubled accounts, as people might have subscribed to the website with a different mail address than to the wiki. We will need to weed out spammer acocunts, something which probably will not be easy.
Also, people like me might say something different from a work email account than from a personal account.
I worry about using the email address as the key, because it makes it very difficult to *preserve* a user's history across address changes. I like my GMail account, but I've had old Comcast or university accounts from which I submitted bugs to RHEL years ago. If I'm not mistaken, index management by numerical keys can often be significantly faster than by text keys.
Am 18.02.11 01:49, schrieb Nico Kadel-Garcia:
I worry about using the email address as the key, because it makes it very difficult to *preserve* a user's history across address changes. I like my GMail account, but I've had old Comcast or university accounts from which I submitted bugs to RHEL years ago. If I'm not mistaken, index management by numerical keys can often be significantly faster than by text keys.
I meant primary key not from a technical, but from a, hmmm, logical viewpoint. If we have double user names, like a "dan" in bugs.c.o and a "dan" on the website, it is not clear if that is the same user. If we have a "dan@example.com" in both dbs, but one has the username "dan", the other "smithd", we can be sure it is the same user.
That is just for the merge. How we address the database later is a completely different issue.
But as said, we are open for ideas :)
Ralph
On Thu, Feb 17, 2011 at 6:49 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
Also, people like me might say something different from a work email account than from a personal account.
I worry about using the email address as the key, because it makes it very difficult to *preserve* a user's history across address changes. I like my GMail account, but I've had old Comcast or university accounts from which I submitted bugs to RHEL years ago. If I'm not mistaken, index management by numerical keys can often be significantly faster than by text keys.
echo "Nico Kadel-Garcia G MM/DD/YYYY Born_in_City, Nation Mother's_Maiden_Name" | md5sum -t 352d6060b85ef831453bd71cfe22e9a9 -
works very well for ISP subscriber account numbers.
On Fri, Feb 18, 2011 at 10:53 PM, Larry Vaden vaden@texoma.net wrote:
On Thu, Feb 17, 2011 at 6:49 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
Also, people like me might say something different from a work email account than from a personal account.
I worry about using the email address as the key, because it makes it very difficult to *preserve* a user's history across address changes. I like my GMail account, but I've had old Comcast or university accounts from which I submitted bugs to RHEL years ago. If I'm not mistaken, index management by numerical keys can often be significantly faster than by text keys.
echo "Nico Kadel-Garcia G MM/DD/YYYY Born_in_City, Nation Mother's_Maiden_Name" | md5sum -t 352d6060b85ef831453bd71cfe22e9a9 -
works very well for ISP subscriber account numbers.
First, md5sum merely makes collisions unlikely, not certain. You'd be wise to check for collisions if you're being careful, even though they're unlikely, and once you've done that, why not simply use incrementing numbers?
And it wouldn't have worked before I got married. My "maiden name" was "Garcia-Otero". I have cousins with that name, whose mother's maiden names was "Otero-[whatever]", and I can think of one whom this would have matched. He died some time back, but such schemes often don't scale well and break down under stress.
Worse, my name changed when I got married. That breaks the indexing algorithm.
So getting back to the original post and discussion....
We could have the username separate from the email side of things and do LDAP lookup on that...
There would still be consistent logins throughout but would be easier for email changes for notification of PMs etc on forums etc.
On Sat, Feb 19, 2011 at 8:18 AM, James Hogarth james.hogarth@gmail.com wrote:
So getting back to the original post and discussion....
We could have the username separate from the email side of things and do LDAP lookup on that...
There would still be consistent logins throughout but would be easier for email changes for notification of PMs etc on forums etc.
Bingo. So the index is......... What? Its own value, typically an incrementing number, just like it is for most sane databases. Tying indexes to integral components of a database is one of the more hateful errors in large project integration that I've had to deal with several times lately.
Bingo. So the index is......... What? Its own value, typically an incrementing number, just like it is for most sane databases. Tying indexes to integral components of a database is one of the more hateful errors in large project integration that I've had to deal with several times lately.
Assuming LDAP then that's not really an issue for that point.
The instance should be properly indexing cname (or whichever value anyway).
The real question is the value used for login... and I would suggest a simple username as opposed to email to make email changing easier and would not cause/require a reindex.
Am 20.02.2011 02:03, schrieb James Hogarth:
The instance should be properly indexing cname (or whichever value anyway).
Yes, of course.
The real question is the value used for login... and I would suggest a simple username as opposed to email to make email changing easier and would not cause/require a reindex.
We do not intend to use the e-mail address as a username. We just intend to identify users in the different legacy account databases based on that.
For example: I got a wiki-account "AndreasRogge" with my e-mail address I got a bugs.c.o account "arogge" with my e-mail address I'm subscribed to the lists with my e-mail address
So the easiest way to identify all my centos accounts in all legacy databases is to look for my e-mail address. This probably works for most users since most people probably just use one mail-address for everything that's related to centos. For those who don't we will probably send out a reminder and ask them to make sure all their accounts have the same address before we merge. The people who are not merged correctly and end up with multiple accounts will have to call "support" to merge their accounts manually.
After the Databases are merged you can (probably) continue to log in using your old username (assuming there were no name-clashes), but you now use the same password for everything and you will be able to use that account for all new CentOS' applications (the Wiki will use the same password, but keep the wikiname-syntax FirstnameLastname).
Eventually we will end up with an account system that contains an e-mail address, a wikiname (for the wiki), a username (for "everything else") and a password.
Besides the merge itself the mail-address won't be used as "username" or "primary key" anywhere it wasn't used before (i.e. mailman).
Regards, Andreas
Am 20.02.11 02:03, schrieb James Hogarth:
The real question is the value used for login... and I would suggest a simple username as opposed to email to make email changing easier and would not cause/require a reindex.
AAAAAAAAAAAARGH!
People, please do not get hung up on the mail adress issue. As I stated before: That seems to be the most sane way to *FIND* accounts by the same person.
NOBODY EVER SAID ANYTHING ABOUT THE TECHNICAL SIDE OF THAT!
Ralph
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/18/2011 06:16 AM, Ralph Angenendt wrote:
First thing: I am sorry that this mail comes this late, it should have been there a week earlier.
Second: At Fosdem we sat together with a round of people, trying to identify which parts CentOS has that are facing to the community, which parts need renewing and which contents should go / has to go where.
As an ordinary user I think, that's really a good idea. And in my opinion you should start with the centos.org homepage.
For somebody, he don't know the details, the CentOS-Project look a little bit dead. That's one reason, why here in asia so many people are using Ubuntu now, and that's really a pity.
Imagine, the could use CentOS with the power of RedHat and they are using Ubuntu, that's not good ...
BTW: Have you ever thought about Drupal for that?
Good luck!
Guenther
- -- DavaoSOFT, the home of ERPel ERPel, das deutsche Warenwirtschaftssystem fuer LINUX http://www.davaosoft.com
I wouldn't use the email due to DB query time plus it makes updating the email address trickier when it changes.
Sent from Android Mobile On 18 Feb 2011 06:24, "Guenther Boelter" gboelter@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/18/2011 06:16 AM, Ralph Angenendt wrote:
First thing: I am sorry that this mail comes this late, it should have been there a week earlier.
Second: At Fosdem we sat together with a round of people, trying to identify which parts CentOS has that are facing to the community, which parts need renewing and which contents should go / has to go where.
As an ordinary user I think, that's really a good idea. And in my opinion you should start with the centos.org homepage.
For somebody, he don't know the details, the CentOS-Project look a little bit dead. That's one reason, why here in asia so many people are using Ubuntu now, and that's really a pity.
Imagine, the could use CentOS with the power of RedHat and they are using Ubuntu, that's not good ...
BTW: Have you ever thought about Drupal for that?
Good luck!
Guenther
DavaoSOFT, the home of ERPel ERPel, das deutsche Warenwirtschaftssystem fuer LINUX http://www.davaosoft.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNXhClAAoJEEazNyJv1SN2/oQH/16/YzhcfGs4vCDhzYYTyFj0 EFVkTAA4qYARkwCfixUWV/G60hjhtbOqtfkeNBT5YzfCxYDuuBkX+t4YRspkODw9 RBD+ztOg4vrFh1jOZd6R9pGJuagmMcqUAZRLHpULTkDtdJR/AFopFUSwEvS1yXK4 pwVW48xL901kwfOFgMHHFXUrOolvvduVCLjj/r++d6CYUTow45hp0jf4TN4TywNb +dcqkTJfVyCXgdxswlrvjTle5MugY1JTFR9OigZe6wVr4gtu60mZIhSwy9y2y0Px yrhUqKeYQBInlMSxv0wlVNA167VlsTOfQE6dxSMkWoW6aHtgGfrrqTRQWnmSl10= =QU1C -----END PGP SIGNATURE----- _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
James Hogarth wrote:
I wouldn't use the email due to DB query time plus it makes updating the email address trickier when it changes.
+1 for normal autoincrement primary key.
Then you can connect several email accounts to that key. Possible enhancement is to make one of the email accounts the primary with special field in the DB. That will designate the master account after the database is normalized.
Ljubomir
Am 18.02.11 09:20, schrieb Ljubomir Ljubojevic:
James Hogarth wrote:
I wouldn't use the email due to DB query time plus it makes updating the email address trickier when it changes.
+1 for normal autoincrement primary key.
Guys, that is just for finding same accounts which might have different user names.
Why does everything have to be *technical* at once when we're first trying to sort how *how* to find same users across the databases?
With LDAP there is no "autoincrement primary key" by the way, if we want to go technical :)
Ralph
Guenther Boelter wrote:
For somebody, he don't know the details, the CentOS-Project look a little bit dead. That's one reason, why here in asia so many people are using Ubuntu now, and that's really a pity.
Imagine, the could use CentOS with the power of RedHat and they are using Ubuntu, that's not good ...
This is not exactly the reason. CentOS 5.x is not really suited for complete Desktop use. I had to add 100-120 packages to my repository from various sources and download locations, and even create ~50 packages (for example latest Skype for CentOS 5.x and binding packages for Open Office 3.2 rpms). Also udev and a lot of other core components are too old for use with newer versions of important desktop applications.
Things will be changed when CentOS 6.0 becomes available. Much has changed in last 3-4 years in Linux desktop world. From new multimedia applications, to wine/wingames support and much larger and more complete hardware support. Even hardware manufacturers have adopted practice to take care about linux drivers.
CentOS 6.x will have modern kernel and core components, but it has stable enviroment and that will be it's booster amongst Desktop distributions. I've waited this moment in time for at least 2 years, for RHEL/CentOS to catch up with Ubuntu and Fedora, but to be rock solid. Modern but bug free, what using Linux should be all about. My belief is that release of 6.0 will be one of the most important moments in CentOS history, and will mark the time when it will start to be more rapidly adopted by general Linux population.
Ljubomir
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/18/2011 04:41 PM, Ljubomir Ljubojevic wrote:
Guenther Boelter wrote:
For somebody, he don't know the details, the CentOS-Project look a little bit dead. That's one reason, why here in asia so many people are using Ubuntu now, and that's really a pity.
Imagine, the could use CentOS with the power of RedHat and they are using Ubuntu, that's not good ...
This is not exactly the reason. CentOS 5.x is not really suited for complete Desktop use.
Ljubomir
Sorry Ljubomir, my mistake, I was not clear in my first post.
No, I'was refering to the 'Ubuntu Server Edition'. And I agree, CentOS is a great OS for a server, it's a little bit pure as a Desktop-Edition, but that's totally ok.
Guenther
- -- DavaoSOFT, the home of ERPel ERPel, das deutsche Warenwirtschaftssystem fuer LINUX http://www.davaosoft.com
Il giorno 17/feb/2011, alle ore 23.16, Ralph Angenendt ha scritto:
Also on the website will be generated content for CentOS. This means the hosting of upstream documentation, automated content via RSS (so planet.centos.org shouldn't be it's own page anymore, those Feeds should be on the website), Twitter feeds and so on. No decision on whose feeds should be found on there have been made yet.
Nice idea! Drupal do have a feed's module!
If you are looking for events, where you can talk to people who are around CentOS should also be found on the website.
Mirrors, mirror status and general infrastructure content will also be on the website.
Downloads for projects within CentOS should also be found here (like Artwork, special CD isos, or whatever you can think of a project within the CentOS eco system)
Aim is to have something which can be automatically filled in parts, and be easy to access and update in the other parts.
The website is for finished things.
I agree with all the above. We just need to define which software to use and then we should just roll up our sleeves and start making this real.
Will wait the next step.
Andrea
Am 18.02.11 18:23, schrieb Andrea Veri:
I agree with all the above. We just need to define which software to use and then we should just roll up our sleeves and start making this real.
Will wait the next step.
Next step is swapping ideas around on how we can make sure to get a clean user database, on how to make a central management "console" for that and on how to best plugin different applications into that.
You want to wait through that or throw some ideas around, too? >:)
Ralph
Il giorno 18/feb/2011, alle ore 21.20, Ralph Angenendt ha scritto:
Am 18.02.11 18:23, schrieb Andrea Veri:
I agree with all the above. We just need to define which software to use and then we should just roll up our sleeves and start making this real.
Will wait the next step.
Next step is swapping ideas around on how we can make sure to get a clean user database,
Asking everyone to register again can be a working solution? :)
on how to make a central management "console" for that and on how to best plugin different applications into that.
why don't we simple use a normal LDAP istance? and why don't we have a look at existing LDAP management consoles like Mango [1] or FAS?
Building one from scratch is definitely not an easy work, so it would be the best to use an existing and tested solutions.
Andrea
[1] http://git.gnome.org/browse/mango [2] https://fedorahosted.org/fas/
Am 20.02.2011 20:25, schrieb Andrea Veri:
Il giorno 18/feb/2011, alle ore 21.20, Ralph Angenendt ha scritto:
Am 18.02.11 18:23, schrieb Andrea Veri:
I agree with all the above. We just need to define which software to use and then we should just roll up our sleeves and start making this real.
Will wait the next step.
Next step is swapping ideas around on how we can make sure to get a clean user database,
Asking everyone to register again can be a working solution? :)
Yeah, but that would break the user's history and ACL. For me it seems too much Web 2.0 to be considered for Enterprise Linux :)
on how to make a central management "console" for that and on how to best plugin different applications into that.
why don't we simple use a normal LDAP istance? and why don't we have a look at existing LDAP management consoles like Mango [1] or FAS?
We need a self-service console which works for our existing applications and can - for example - solve "the wikiname problem" (i.e. different usernames based on the application accessed) We want to start out with a plain LDAP because it is widely supported by the applications we intend to use. We can still move somewhere else later as long as that one supports ldap-queries (i.e. IPA, Mango, whatever). The problem I see with FAS is that we'd need to change our applications to support it. For ldap it is usually just a few configuration-switches.
Building one from scratch is definitely not an easy work, so it would be the best to use an existing and tested solutions.
Depends. There are centos people who are quite into ldap and while we need some weird stuff the whole thing is rather simple.
Regards, Andreas
On 02/21/2011 12:29 PM, Andreas Rogge wrote:
Building one from scratch is definitely not an easy work, so it would be the best to use an existing and tested solutions.
Depends. There are centos people who are quite into ldap and while we need some weird stuff the whole thing is rather simple.
I agree with this. the level of complexity introduced by trying to wrangle an existing solution into working for the various properties / resources we have might be a lot higher than just doing something simple from scratch.
- KB
Am 20.02.11 20:25, schrieb Andrea Veri:
Il giorno 18/feb/2011, alle ore 21.20, Ralph Angenendt ha scritto:
Am 18.02.11 18:23, schrieb Andrea Veri:
I agree with all the above. We just need to define which software to use and then we should just roll up our sleeves and start making this real.
Will wait the next step.
Next step is swapping ideas around on how we can make sure to get a clean user database,
Asking everyone to register again can be a working solution? :)
I am not sure. Not if we try to retain knowledge by keeping old forums along.
on how to make a central management "console" for that and on how to best plugin different applications into that.
why don't we simple use a normal LDAP istance?
You'd still need something where users can sign up/sign out/change things?
and why don't we have a look at existing LDAP management consoles like Mango [1] or FAS?
See, that's why this asking around happens :) Not everybody does know anything.
Building one from scratch is definitely not an easy work, so it would be the best to use an existing and tested solutions.
If one can integrate them with what is there - sure, why not.
Ralph
On 02/17/2011 10:16 PM, Ralph Angenendt wrote:
- Wiki
The wiki will find it's role as being about the distribution side of things (read on for an explanation). All documentation about the project
...
- Website
The website will be about the project side of things. Firstly it should be a starting point for all users - a role which it does not really play
...
Clear division of which content will go where. This also means that a clearer presentation of content can be done on all parts, not the muddle we have there at the moment.
I'm guessing that there is some level of agreement on the content split between wiki and website. This is an important issue, since pretty much everything we do from here would depend on putting that line down and then asking people to stick to that split.
Links between forum posts might go away, I am not sure if there is a possibility to find out the new target of a link.
We can prolly work on that - and maybe even get a 30x redirect from the old url to the new url ( for a few months, so people can update bookmarks etc )
- KB
2011/2/17 Ralph Angenendt ralph.angenendt@gmail.com:
What we did not discuss was which software should be used where, although for many pieces this already has been chosen.
Let me try to make it a bit more clear:
We have (technical) solutions for:
wiki.centos.org (stays the same, auth will be different) projects.centos.org (will still be trac, auth will be different) bugs.centos.org (mantis, different auth) forums (we already have migrations scripts into php-bb).
Everything else is open for discussion.
What is needed:
Go over the web content. Identify articles which need to stay (or should be ported to the wiki) or which can go away. All this outside of the forums.
Suggestions for a working LDAP frontend, suggestions for a working LDAP schema (which attributes are needed, and so on).
Suggestions for a solution for the web site - please no "Joompal3, because I've used it once", but more like "DruTyPress 4, because we already fed RSS feeds to that, This wanted feature also can be implemented easily, Oh, and it has a bridge to php-bb".
People who can adapt the wiki css to things to come.
Does that make the venture a bit clearer?
Regards,
Ralph
Il giorno 23/feb/2011, alle ore 13.56, Ralph Angenendt ha scritto:
Suggestions for a solution for the web site - please no "Joompal3, because I've used it once", but more like "DruTyPress 4, because we already fed RSS feeds to that, This wanted feature also can be implemented easily, Oh, and it has a bridge to php-bb".
Drupal:
1. it has feeds support and they are easy to implement 2. it is easy to maintain by multiple people and easy to develop while working in a work-group. 3. it has LDAP integration 4. works fine on CentOS since we currently have the needed packages in EPEL. (so easy to upgrade or recover directly from RPMs) 5. we can link it to the phpbb istance with no problem, a link on the header or anywhere else on the frontpage will just do what we need. 6. we currently use it in Fedora and we have several nice pages to have it set up together with some nice modules 7. it is easy to deploy on puppet 8. even the White House use it on their websites!
Ralph, is this not enough?
Andrea
Andrea Veri wrote:
Drupal:
-snip-
- works fine on CentOS since we currently have the needed packages
in EPEL. (so easy to upgrade or recover directly from RPMs)
I have one off-topic question.
Where is Drupal installed from RPM? /var/www/html? What about multiple domain servers? I am using Virtualmin on my server, is there any "copy" script so I could make a copy of default Drupal instance inside the /home/domain/html path?
Thanks, Ljubomir
Il giorno 23/feb/2011, alle ore 14.50, Ljubomir Ljubojevic ha scritto:
Andrea Veri wrote:
Drupal:
-snip-
- works fine on CentOS since we currently have the needed packages
in EPEL. (so easy to upgrade or recover directly from RPMs)
I have one off-topic question.
Where is Drupal installed from RPM? /var/www/html? What about multiple domain servers? I am using Virtualmin on my server, is there any "copy" script so I could make a copy of default Drupal instance inside the /home/domain/html path?
For a list of file, just grab the drupal rpm and do:
repoquery --list package-name.rpm
For the rest you should read an Apache guide, there is plenty on the web about virtual hosts etc.
cheers,
Andrea
Andrea Veri wrote:
Il giorno 23/feb/2011, alle ore 14.50, Ljubomir Ljubojevic ha scritto:
Andrea Veri wrote:
Drupal:
-snip-
- works fine on CentOS since we currently have the needed packages
in EPEL. (so easy to upgrade or recover directly from RPMs)
I have one off-topic question.
Where is Drupal installed from RPM? /var/www/html? What about multiple domain servers? I am using Virtualmin on my server, is there any "copy" script so I could make a copy of default Drupal instance inside the /home/domain/html path?
For a list of file, just grab the drupal rpm and do:
repoquery --list package-name.rpm
For the rest you should read an Apache guide, there is plenty on the web about virtual hosts etc.
cheers,
Andrea
I use virtual hosts for 3-4 years now, and I have built 8-10 Joomla sites so far, but always by unpacking the zip into virtual hosts folder. Updates are the same. So this is not an issue for me.
I was asking about deployment after RPM is installed, are better yet updated, can that upgrade be automated or not. So my query is with RPM deployment, not Drupal itself.
Nevermind, I'll browse trough changelog/readme files and find out.
Ljubomir
On 02/23/2011 01:06 PM, Andrea Veri wrote:
Suggestions for a solution for the web site - please no "Joompal3,
Drupal:
- it has feeds support and they are easy to implement
On the flip side : if primary content on the website is going to be generated / project based rather than lots of text / cms style content; then do we need much more than a few static pages with the right css thrown in on top - and let the apps run as they do with the same css ( as much as possible ).
Would drupal in this case not be a total overkill ?
- KB
Il giorno 23/feb/2011, alle ore 19.00, Karanbir Singh ha scritto:
On 02/23/2011 01:06 PM, Andrea Veri wrote:
Suggestions for a solution for the web site - please no "Joompal3,
Drupal:
- it has feeds support and they are easy to implement
On the flip side : if primary content on the website is going to be generated / project based rather than lots of text / cms style content; then do we need much more than a few static pages with the right css thrown in on top - and let the apps run as they do with the same css ( as much as possible ).
Would drupal in this case not be a total overkill ?
Going with static pages would be nice yes, but it is not really easy to maintain. We would need a git repo with special permissions and whatever. Drupal with its own account management can simplify this duty and allow multiple people to edit only part of the content available on the website. (i.e we have the administrator role that can modify modules, and pretty much everything, we do have the editor role that can modify just stories and other minor things)
On a drupal istance adding and managing content is really easy, while doing a website from scratch (css, html, php, ...) can take more time to be developed and can take some of us to disagree on how the website will look like. (building a website requires a project and a lot of work to organize the content itself and its structure, while this won't actually happen with Drupal, since any of us have seen or played with a working drupal istance before today and know how and where the content is managed)
Adopting static pages can be hard to maintain for a team, yet another vcs to push stuff to. But anyway I am open to any idea, my main interest is to change things making the current website a bit more useful and nice.
Just my two cents.
Andrea
----- Original Message ----- | Il giorno 23/feb/2011, alle ore 19.00, Karanbir Singh ha scritto: | | > On 02/23/2011 01:06 PM, Andrea Veri wrote: | >>> Suggestions for a solution for the web site - please no "Joompal3, | >> | >> Drupal: | >> | >> 1. it has feeds support and they are easy to implement | > | > On the flip side : if primary content on the website is going to be | > generated / project based rather than lots of text / cms style | > content; | > then do we need much more than a few static pages with the right css | > thrown in on top - and let the apps run as they do with the same css | > ( | > as much as possible ). | > | > Would drupal in this case not be a total overkill ? | | Going with static pages would be nice yes, but it is not really | easy to maintain. We would need a git repo with special permissions | and whatever. Drupal with its own account management can simplify | this duty and allow multiple people to edit only part of the content | available | on the website. (i.e we have the administrator role that can modify | modules, | and pretty much everything, we do have the editor role that can modify | just | stories and other minor things) | | On a drupal istance adding and managing content is really easy, while | doing a website from scratch (css, html, php, ...) can take more time | to be | developed and can take some of us to disagree on how the website will | look like. | (building a website requires a project and a lot of work to organize | the content | itself and its structure, while this won't actually happen with | Drupal, since any of | us have seen or played with a working drupal istance before today and | know | how and where the content is managed) | | Adopting static pages can be hard to maintain for a team, yet another | vcs to | push stuff to. But anyway I am open to any idea, my main interest is | to change | things making the current website a bit more useful and nice. | | Just my two cents. | | Andrea
I would highly recommend using CVS to maintain the base Drupal and third party module instances. Using CVS with the appropriate stable tags makes it easy to upgrade from version to version and makes maintenance of the thousands of Drupal modules much easier.
----- Original Message ----- | ----- Original Message ----- | | Il giorno 23/feb/2011, alle ore 19.00, Karanbir Singh ha scritto: | | | | > On 02/23/2011 01:06 PM, Andrea Veri wrote: | | >>> Suggestions for a solution for the web site - please no | | >>> "Joompal3, | | >> | | >> Drupal: | | >> | | >> 1. it has feeds support and they are easy to implement | | > | | > On the flip side : if primary content on the website is going to | | > be | | > generated / project based rather than lots of text / cms style | | > content; | | > then do we need much more than a few static pages with the right | | > css | | > thrown in on top - and let the apps run as they do with the same | | > css | | > ( | | > as much as possible ). | | > | | > Would drupal in this case not be a total overkill ? | | | | Going with static pages would be nice yes, but it is not really | | easy to maintain. We would need a git repo with special permissions | | and whatever. Drupal with its own account management can simplify | | this duty and allow multiple people to edit only part of the content | | available | | on the website. (i.e we have the administrator role that can modify | | modules, | | and pretty much everything, we do have the editor role that can | | modify | | just | | stories and other minor things) | | | | On a drupal istance adding and managing content is really easy, | | while | | doing a website from scratch (css, html, php, ...) can take more | | time | | to be | | developed and can take some of us to disagree on how the website | | will | | look like. | | (building a website requires a project and a lot of work to organize | | the content | | itself and its structure, while this won't actually happen with | | Drupal, since any of | | us have seen or played with a working drupal istance before today | | and | | know | | how and where the content is managed) | | | | Adopting static pages can be hard to maintain for a team, yet | | another | | vcs to | | push stuff to. But anyway I am open to any idea, my main interest is | | to change | | things making the current website a bit more useful and nice. | | | | Just my two cents. | | | | Andrea | | | I would highly recommend using CVS to maintain the base Drupal and | third party module instances. Using CVS with the appropriate stable | tags makes it easy to upgrade from version to version and makes | maintenance of the thousands of Drupal modules much easier. | | -- | James A. Peltier | IT Services - Research Computing Group | Simon Fraser University - Burnaby Campus | Phone : 778-782-6573 | Fax : 778-782-3045 | E-Mail : jpeltier@sfu.ca | Website : http://www.sfu.ca/itservices | http://blogs.sfu.ca/people/jpeltier
Sorry, hit send too early
See: Checking out from the main repository
On 02/24/2011 05:23 AM, James A. Peltier wrote:
| I would highly recommend using CVS to maintain the base Drupal and | third party module instances. Using CVS with the appropriate stable | tags makes it easy to upgrade from version to version and makes | maintenance of the thousands of Drupal modules much easier.
There are tools like drush and aegir which are designed to plug into puppet et al, and keep your site up to date. At a pinch, if we really want to go down that path, we can even pull a patch set and apply just the diffs as the code base evolves.
Management of the CMS is not the issue, it's the functionality and suitability of what we use for the task, be it Wordpress, Drupal, Joomla or ${select * from cms.favorites where type = 'php';}.
My preference is Drupal, mainly due to my experience with it, but I'd done similar site with wordpress as well. There are ways to mitigate the exploits and attacks that will come from running a php (or any type of ) CMS, but they're to be discussed down the track.
regards
Steve
On 02/23/2011 06:13 PM, Andrea Veri wrote:
Adopting static pages can be hard to maintain for a team, yet another vcs to push stuff to. But anyway I am open to any idea, my main interest is to change things making the current website a bit more useful and nice.
if its dozens of pages, I'd agree. But in this case we might be talking about potentially 1 page.
- KB
CMS = possible security woes.
Certainly not worth the headache for a one page footprint.
On Wed, Feb 23, 2011 at 4:03 PM, Karanbir Singh mail-lists@karan.orgwrote:
On 02/23/2011 06:13 PM, Andrea Veri wrote:
Adopting static pages can be hard to maintain for a team, yet another vcs
to
push stuff to. But anyway I am open to any idea, my main interest is to
change
things making the current website a bit more useful and nice.
if its dozens of pages, I'd agree. But in this case we might be talking about potentially 1 page.
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Hi,
On 02/23/2011 09:03 PM, Karanbir Singh wrote:
Adopting static pages can be hard to maintain for a team, yet another vcs to push stuff to. But anyway I am open to any idea, my main interest is to change things making the current website a bit more useful and nice.
I am wondering if a critical bit of info isnt clear or missing. Expanding on the original email the idea was :
- Split all user contributed and distro specific stuff to the wiki, leaving the website as a first-point-of-reference and a link amalgamation into various resources. With all app and generated content being hosted behind www.c.o; the forums etc would move wherever they need to, if they need to - its not related to the website.
Now, the issue as to why I *think*, and might be wrong, is that apart from the homepage and perhaps a few other pages, the content behind the website is going to all come from python / perl / php apps (scripts ?), at the moment, and I can quite imagine a bit of ruby making an entrance soon.
Also, when I say homepage and a few more pages, it *might* be that count(few more pages) = 0;
- KB
On Wed, 23 Feb 2011 19:13:53 +0100 Andrea Veri av@gnome.org wrote:
Il giorno 23/feb/2011, alle ore 19.00, Karanbir Singh ha scritto:
On 02/23/2011 01:06 PM, Andrea Veri wrote:
Suggestions for a solution for the web site - please no "Joompal3,
Drupal:
- it has feeds support and they are easy to implement
On the flip side : if primary content on the website is going to be generated / project based rather than lots of text / cms style content; then do we need much more than a few static pages with the right css thrown in on top - and let the apps run as they do with the same css ( as much as possible ).
Would drupal in this case not be a total overkill ?
Going with static pages would be nice yes, but it is not really easy to maintain. We would need a git repo with special permissions and whatever. Drupal with its own account management can simplify this duty and allow multiple people to edit only part of the content available on the website. (i.e we have the administrator role that can modify modules, and pretty much everything, we do have the editor role that can modify just stories and other minor things)
On a drupal istance adding and managing content is really easy, while doing a website from scratch (css, html, php, ...) can take more time to be developed and can take some of us to disagree on how the website will look like. (building a website requires a project and a lot of work to organize the content itself and its structure, while this won't actually happen with Drupal, since any of us have seen or played with a working drupal istance before today and know how and where the content is managed)
As a small website owner who uses Drupal and having moved from static hmtl I am considering going back to static html with css (once I learn a few more css tricks), and then adding phpbb for the very low-volume message traffic on my site. I do like Drupal but imho it's a pita to keep updated. Of course it would depend on what modules you use, also. I have pared down my module set to as few as possible, but sometimes an update requires having to learn how to re-do permissions for the module or other settings that are introduced have to be configured, or they don't play well with the content.
One example of not playing well with the content is the 'footnotes' module; which I plan to remove as soon as I can go through my few articles and hand-code the html for the few footnotes I have. On the 'input type' for content the default is filtered html, then there's full html and a 3rd option is 'footnotes'. Even if there aren't any footnotes on a page, unless I select that input type all the formatting for the paragraphs disappears and everything runs into a big blob of text. I haven't worked very hard to see if it's a bug I should report or not, I'm just reminded of the issue when I post something.
So, if you're using 'basic Drupal' with no modules or very very few of them, it might not be an issue. But for my small site, the maintenance and changes that come with it that have to be dealt with have me looking to other options. Initially setting up the css and possibly other things might be a hassle, but over time it might be the way to go.
Am 23.02.2011 19:00, schrieb Karanbir Singh:
On the flip side : if primary content on the website is going to be generated / project based rather than lots of text / cms style content; then do we need much more than a few static pages with the right css thrown in on top - and let the apps run as they do with the same css ( as much as possible ).
Would drupal in this case not be a total overkill ?
Maybe, maybe not.
But not having a CMS will become a maintenance-horror either. There is no site that only aggregates feeds, there's always some content left (i.e. you don't intend to generate "Download CentOS X"-Buttons by crafting weird CSS-voodoo around an rss feed, do you?) and you have to somehow organize the feeds you display.
So we need something that is good at news aggregation and that has at least a few cms features.
I don't vote for Drupal (and also not against it). But I strongly discourage the "just some static pages"-solution.
Regards, Andreas
On 3/1/11 1:54 AM, Andreas Rogge wrote:
But not having a CMS will become a maintenance-horror either. There is no site that only aggregates feeds, there's always some content left (i.e. you don't intend to generate "Download CentOS X"-Buttons by crafting weird CSS-voodoo around an rss feed, do you?) and you have to somehow organize the feeds you display.
I don't necessarily agree, depending on the number of pages. Assuming, of course, that some PHP or other scripting is allowed on the back end to do some simple stuff like grabbing and caching RSS feeds before generating the page.
If you're using a CMS to manage just a couple pages, then you're probably fighting with the CMS to make it work the way you want it to. With just a few pages, the benefits aren't as significant.
Steve
Am 01.03.2011 19:31, schrieb Steve Meyers:
If you're using a CMS to manage just a couple pages, then you're probably fighting with the CMS to make it work the way you want it to.
If you're "fighting" with your CMS you're definitely using the wrong tool for the job.
With just a few pages, the benefits aren't as significant.
They obviously are. It is "learn to use git and how to program php" and "try to understand the code you wrote two years ago" vs. "have a look at the 5 minute CMS introduction video" for being able to edit the page.
As I already said: we need something that's good at aggregation and can do simple cms stuff. I don't say Drupal/Joomla/whatever is the right tool, but plain PHP with code + content mixed up is just a pain.
So we'll either end up with an CMS or some php "framework" (maybe just a few libs thrown together) to make editing the page rather simple. I guess the latter one would work, but I doubt it has any real advantages over a _simple_ cms+aggregator solution.
"Lets to it with php ourselves" sounds like a NIH-problem to me and will become a maintenance-horror in the long run.
Regards, Andreas
On 3/1/11 12:59 PM, Andreas Rogge wrote:
If you're "fighting" with your CMS you're definitely using the wrong tool for the job.
I guess that's why I don't like to use CMSes. I like to have more control over layout and such, and I find I spend less time doing my own CSS and HTML than I would trying to get my CSS to work within the CMS CSS. The more customizing you do with the CMS, the more problems you potentially have when you do upgrades in the future.
Like I said though, it all depends on how many pages you're maintaining. At some point, it's better to just work within the bounds of the CMS and give up some of the customizability, in order to have better maintainability.
I'm saying all this without having seen a site design for the new website, so perhaps I should just keep my piehole shut.
Steve
Dear Steve.
I guess that's why I don't like to use CMSes. I like to have more control over layout and such, and I find I spend less time doing my own CSS and HTML than I would trying to get my CSS to work within the CMS CSS. The more customizing you do with the CMS, the more problems you potentially have when you do upgrades in the future.
Like I said though, it all depends on how many pages you're maintaining. At some point, it's better to just work within the bounds of the CMS and give up some of the customizability, in order to have better maintainability.
Please don't worry to much about theming. CSS Stylesheet is already there and will be ported to themes if necessary.
Greets Marcus
Am 01.03.2011 21:09, schrieb Steve Meyers:
I guess that's why I don't like to use CMSes. I like to have more control over layout and such, and I find I spend less time doing my own CSS and HTML than I would trying to get my CSS to work within the CMS CSS. The more customizing you do with the CMS, the more problems you potentially have when you do upgrades in the future.
That's still the "wrong tool" problem i was talking about. Don't use a CMS that puts its own CSS onto your page. Its job is to manage content not design. It is absolutely ok if you write the page template from scratch. But design, code and content should be separated so you can replace each of them without having to think too much about the other two. Using a ready-made solution makes sure that: - the code/content/design-separation is there - the libraries used are known to work together - you don't need to hack around getting RSS import or whatever to work - you have an upgradable vendor-provided codebase (which you should never touch)
Regards, Andreas
Am 01.03.11 20:59, schrieb Andreas Rogge:
"Lets to it with php ourselves" sounds like a NIH-problem to me and will become a maintenance-horror in the long run.
s/php/favorite toy language/
+1, I want to have something maintanable. Well, except if you just cobble three scripts together even I can understand :)
Ralph
Am 23.02.11 13:56, schrieb Ralph Angenendt:
What is needed:
Go over the web content. Identify articles which need to stay (or should be ported to the wiki) or which can go away. All this outside of the forums.
Suggestions for a working LDAP frontend, suggestions for a working LDAP schema (which attributes are needed, and so on).
Suggestions for a solution for the web site - please no "Joompal3, because I've used it once", but more like "DruTyPress 4, because we already fed RSS feeds to that, This wanted feature also can be implemented easily, Oh, and it has a bridge to php-bb".
People who can adapt the wiki css to things to come.
Does that make the venture a bit clearer?
And as work arises, the thread dies. There were several people wanting to help with website v2. Up there are several things which need to be done before there is the need to decide which software runs where.
*sigh*
Ralph
-
Andrea Veri -
Andreas Rogge -
Cia Watson -
Guenther Boelter -
James A. Peltier -
James Hogarth -
Karanbir Singh -
Larry Vaden -
Ljubomir Ljubojevic -
Marcus Moeller -
Nico Kadel-Garcia -
Philippe Laurent -
Ralph Angenendt -
Stephen Walsh -
Steve Meyers