You are not logged in.
Thanks B... vim doesn't have spell check
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Thanks B... vim doesn't have spell check
that's weird .
I recall using ":set spell" and "z=" frequently . Maybe I use vim a lot in my dreams!
English is not my native language .
Offline
that's weird .
I recall using ":set spell" and "z=" frequently . Maybe I use vim a lot in my dreams!
And this is why I'm not dead yet... I still learn something new every day!
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Well slap my ass and call me Sally!
I hope you guys take this all the way. I wish you the best!
Offline
Well slap my ass and call me Sally!
I hope you guys take this all the way. I wish you the best!
Thanks Sally!
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Trying to get the social networking thing going
http://identi.ca/group/archserver
EDIT: ghost1227 already created a group, so fixed this up... Thanks ghost1227
Last edited by fukawi2 (2009-10-19 02:25:53)
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Good Luck, I'd definitely be interested in using it once its in a usable state. I wish I could help, but I honestly don't know enough or have the time :$. Looking forward to seeing your progress.
-Jimi
Last edited by Jimi (2009-10-19 04:29:41)
Offline
I can offer to test if there is such a need when its at that stage.
I appreciate your efforts and wish you best of luck.
Offline
If you still need help with website thingies count me in
Offline
your wiki says that lts doesnt support ext4, but arch/fedora's package has a patch for that.
also, is this going to be a distro?
Last edited by gog (2009-10-20 20:55:03)
Offline
I can offer to test if there is such a need when its at that stage.
I appreciate your efforts and wish you best of luck.
Thank-you
Could you add your contact details (obfuscated is fine of course) to the wiki page? Testers will be very important
http://www.archserver.org/wiki/index.php?title=Signup
If you still need help with website thingies count me in
Ghost1227 has volunteered to help out with that, but feel free to pull a copy from github and make any improvements you think can be done. It's really a bad hack at the moment!
your wiki says that lts doesnt support ext4, but arch/fedora's package has a patch for that.
also, is this going to be a distro?
That's something that I need input from community on -- for a server distro, do we want to patch an LTS kernel to provide that support for ext4, or if you need ext4, are we happy to go with the standard kernel, keeping in mind that the kernel release won't change during a release (eg, 2.6.30 -> 2.6.31) unless of course the input from the community says that's desired.
And I don't know if I'd call it a separate distro to Arch, not at this stage anyway... It's more just an extension for now
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Ok I regitered on the wiki but not sure what I need to do after that...:/
I see the forum is not installed/running yet there? I could also get that started, unless someone has already.
Offline
gog wrote:your wiki says that lts doesnt support ext4, but arch/fedora's package has a patch for that.
That's something that I need input from community on -- for a server distro, do we want to patch an LTS kernel to provide that support for ext4, or if you need ext4, are we happy to go with the standard kernel, keeping in mind that the kernel release won't change during a release (eg, 2.6.30 -> 2.6.31) unless of course the input from the community says that's desired.
The patch to support ext4 just renames the filesystem from "ext4dev" to "ext4". All the rest of ext4 is backported upstream.
Offline
Ok I regitered on the wiki but not sure what I need to do after that...:/
Hopefully you should have gotten an email confirmation to activate your account, then you can edit away on the wiki
I see the forum is not installed/running yet there? I could also get that started, unless someone has already.
No forum at the moment -- if the project starts to get legs then I'll put some time into getting it going, but want to focus more on the packages etc first.
The patch to support ext4 just renames the filesystem from "ext4dev" to "ext4". All the rest of ext4 is backported upstream.
So the 'ext4dev' code is actually the stable 'ext4' code, even in 2.6.27?
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Allan wrote:The patch to support ext4 just renames the filesystem from "ext4dev" to "ext4". All the rest of ext4 is backported upstream.
So the 'ext4dev' code is actually the stable 'ext4' code, even in 2.6.27?
I believe that everything has been backported upstream, so yes.
Offline
Interesting... That will be good.
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
I sort of do this already, not on a wide scale basis mind you, but for myself.
1. Mirror Current Repo to a Local Repo
2. Use local Repo on test servers
3. If no issues, push local Repo to Stable Repo
4. Upgrade servers from Stable Repo
5. Pull Current Repo to local repo and start over with testing again.
--------------------------
| Current Internet Repos |
--------------------------
|
|
----------------------
| Local Repo-Testing | ----- Test Servers
----------------------
|
|
--------------------
| New Repo - Stable | -->>->>- Stable Servers
--------------------
I haven't ignored any packages for my setups, I upgrade kernels and do all upgrades, I just test them locally on 3 test server machines before I do my remote production server upgrades.
Has worked pretty well for me. You could ignore kernel upgrades I suppose and make the thing even more painless to do, but for me the whole point of running Arch is to be as close to the newest releases on all software. I don't have time to create my own packages, and I never saw the need to duplicate the stuff that has already been done. For me, creating my own "stable" Arch server, has been 99% testing before updating the production server. So basically I create my own stable server repo through testing.
My setup works for me, but I'm really only tracking/working with (sshd openntpd mysqld httpd postfix proftpd) for the most part. As long as those are stable and issues dealt with/figured out, then the production server is usually happy. Archlinux.me downtime has been 100% hardware related, and not due to any problems with Arch itself. A very brief downtime while converting to php 5.3, but that was pretty minor.
I honestly haven't looked at kernel26-lts ....... probably should I suppose, but the regular kernel has always worked pretty well.
Anyway, just thought I'd share how I do this for myself.
Offline
i think that basing a stable whatever from arch is flawed from the start
the package upgrade process is too fast. because most packages have very short lives between versions, we are always upstream!
Offline
i think that basing a stable whatever from arch is flawed from the start
the package upgrade process is too fast. because most packages have very short lives between versions, we are always upstream!
Well, then you are obviously not the target audience.
Offline
i think that basing a stable whatever from arch is flawed from the start
That's fine, you don't have to use it
the package upgrade process is too fast. because most packages have very short lives between versions, we are always upstream!
That's what's going to be different -- we will be working on a more traditional release style upgrade system, rather than a constantly changing rolling release.
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
what package fits the criteria for stable enough, in arch i mean
what are you going to base it on? im not criticizing i just want to understand
debian for example would have years of logs and user input on a given package... a crusty old repatched to hell and back package. where's that in arch? all the mirrors get repopulated on every sync, theres no legacy
i mean, even something as basic for a stable development team, pacman handling multiple versions, isnt there. are you planning to hack pacman? chroot all over the place? install to opt?
Last edited by gog (2009-10-21 12:06:49)
Offline
what package fits the criteria for stable enough, in arch i mean
Holding a package version at a minor and only bumping revisions. Eg, instead of jumping to php 5.3, hold at 5.2 and only take the revisions (currently 5.2.11), backporting security fixes where required / possible.
what are you going to base it on? im not criticizing i just want to understand
I'm not sure if I understand this question -- it's going to be based on Arch......
debian for example would have years of logs and user input on a given package... a crusty old repatched to hell and back package. where's that in arch? all the mirrors get repopulated on every sync, theres no legacy
We'll have our own repository / mirrors which will only hold whatever packages we build and push.
i mean, even something as basic for a stable development team, pacman handling multiple versions, isnt there. are you planning to hack pacman? chroot all over the place? install to opt?
There's no plans to hack pacman, although it may happen if a goal of the project requires it I guess. There's been no discussion about having multiple versions of software installed -- where are you getting that idea from?
Last edited by fukawi2 (2009-10-21 22:05:56)
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
i think that basing a stable whatever from arch is flawed from the start
the package upgrade process is too fast. because most packages have very short lives between versions, we are always upstream!
OMG...... flawed.....whatever.
There are 3 distinct views on updates in the server world as far as I'm concerned.
1. Update frequently to keep up with security updates.
2. Use "stable" distro's and use their security patches.
3. Don't update -- it might break something.
99% of the time, Arch has a newer version of php/mysql/apache than does say RHEL.
So, while it may not be as "tested" as other stable "patches/distros", it's probably more cutting edge and has more security patches already included.
I think WAY more people in the server world fall into category #3 than anyone would probably admit. The "corporate world" tends to fall into #3 or #2.
I think an Arch Server does #1 better than the others.... patches are faster, and it's a rolling release distro.... no nasty dist-upgrades etc...
Everyone is always saying you shouldn't use Arch as a server distro because it's too bleeding edge, but it really depends on what your wanting your server to do.
ALSO..... my setup shown above might actually SKIP an updated package....... I sync to the main repo....test until i'm sure things are working ok.... and then push them to the production machine.
This might take a week or two.....then I start the process all over again... it is entirely possible that in that amount of time I may have missed some package that perhaps updated two or three times in that time span..... so what. As long as my updates don't break my server..... I'm happy. I have several servers running Arch as their distro. Archlinux.me (plus a few more sites) on one server, python3.org (along with about 12 other sites) on a different server...... both working great.
Personally, I think using Arch as a server distro is a brilliant thing...and if there were just a bit of testing done before pushing updates that could break your system, just to make sure they don't.... it would be amazing, as you could script your updates to run nightly.......and guess what, I HAVE done that with desktop machines in the office. I've had one or two hiccups before, but the test machines caught the problems before they were pushed to the production stuff. But then again.......maybe I'm just one of Arch Linux's biggest fans.
Offline
I sort of do this already, not on a wide scale basis mind you, but for myself.
1. Mirror Current Repo to a Local Repo
2. Use local Repo on test servers
3. If no issues, push local Repo to Stable Repo
4. Upgrade servers from Stable Repo
5. Pull Current Repo to local repo and start over with testing again.-------------------------- | Current Internet Repos | -------------------------- | | ---------------------- | Local Repo-Testing | ----- Test Servers ---------------------- | | -------------------- | New Repo - Stable | -->>->>- Stable Servers --------------------
I haven't ignored any packages for my setups, I upgrade kernels and do all upgrades, I just test them locally on 3 test server machines before I do my remote production server upgrades.
Has worked pretty well for me. You could ignore kernel upgrades I suppose and make the thing even more painless to do, but for me the whole point of running Arch is to be as close to the newest releases on all software. I don't have time to create my own packages, and I never saw the need to duplicate the stuff that has already been done. For me, creating my own "stable" Arch server, has been 99% testing before updating the production server. So basically I create my own stable server repo through testing.My setup works for me, but I'm really only tracking/working with (sshd openntpd mysqld httpd postfix proftpd) for the most part. As long as those are stable and issues dealt with/figured out, then the production server is usually happy. Archlinux.me downtime has been 100% hardware related, and not due to any problems with Arch itself. A very brief downtime while converting to php 5.3, but that was pretty minor.
I honestly haven't looked at kernel26-lts ....... probably should I suppose, but the regular kernel has always worked pretty well.Anyway, just thought I'd share how I do this for myself.
Brilliant. The simple, elegant and perfect solution.
Offline