OpenLiteSpeed users

[TPerry]

Just a heads up... version 1.3.1 has just been released. I'm about to grab it and compile for Debian and install and see if they fixed the 1.3 bugs. If you use centOS and installed their RPM package it should be available via your yum update.

EDIT:
First compile/install done on one of the forums.. and it appears that the CSS display bug that they had is fixed. Also seems to be a little faster (might be my imagination or the new server I moved to though ).

They also fixed the problem on Debian when you compile and upgrade and existing OLS install that it had stomped several of the settings (namely the administrators logon).

 

[Floren]

Is your imagination... Nginx is the fastest in the world. I had to say it, hehe.

 

[TPerry]

Is your imagination... Nginx is the fastest in the world. I had to say it, hehe.

I've ran both... and their both pretty much neck and neck.
OLS (once you learn the GUI) is a little more friendly to quick changes.

 

[Floren]

And you say you prefer a terminal... next for you is to install a panel, hehe.

 

[TPerry]

And you say you prefer a terminal... next for you is to install a panel, hehe.

Just makes it a little quicker for some of the finer features for settings... not to mention for the HTTP server it's easier to do from the remote locations I need to. The way I have my SSH configured coming in from remote is a "little" convoluted due to security I have in place.
And I'm teaching my wife how to help out with the servers - and SSH is more than she can do.
Everything that you can do via the web interface can also be done via SSH and nano.

 

[Floren]

Yes, excuses on top of excuses. Get rid of that GUI ASAP! (obviously, I'm joking around)

 

[TPerry]

Yes, excuses on top of excuses. Get rid of that GUI ASAP! (obviously, I'm joking around)

This look friendly enough?

<?xml version="1.0" encoding="UTF-8"?>
<virtualHostConfig>
  <docRoot>$VH_ROOT/html/</docRoot>
  <enableGzip>1</enableGzip>
  <logging>
    <log>
      <useServer>0</useServer>
      <fileName>$VH_ROOT/logs/error.log</fileName>
      <logLevel>DEBUG</logLevel>
      <rollingSize>10M</rollingSize>
    </log>
    <accessLog>
      <useServer>0</useServer>
      <fileName>$VH_ROOT/logs/access.log</fileName>
      <rollingSize>10M</rollingSize>
      <keepDays>30</keepDays>
      <compressArchive>0</compressArchive>
    </accessLog>
  </logging>
  <index>
    <useServer>0</useServer>
    <indexFiles>index.php, index.html</indexFiles>
    <autoIndex>0</autoIndex>
    <autoIndexURI>/_autoindex/default.php</autoIndexURI>
  </index>
  <customErrorPages>
    <errorPage>
      <errCode>404</errCode>
      <url>/error404.html</url>
    </errorPage>
  </customErrorPages>
  <scriptHandlerList>
    <scriptHandler>

 

[Floren]

This look friendly enough?

https://servinglinux.com/threads/http-server-change.136/

 

[TPerry]

https://servinglinux.com/threads/http-server-change.136/

Yep, I was under the impression that 1.3.1 was stable code - turns out it's developmental code. OLS 1.2.9 works fine on it - but I got tired of hassling with it all the time so I've converted the XenForo forums back over to nginx/php5-fpm. My WP blog sites I just regressed back to 1.2.9 on OLS.

Once 1.3.x stable series comes out I may go back over to it (simple matter of re-assigning ownership of the forum files).

 

[Floren]

I think is time to stick with an "always stable" product, @Tracy Perry?

 

[TPerry]

I think is time to stick with an "always stable" product, @Tracy Perry?

Oh, you and I both know that there is the stable branch of nginx and the unstable branch of code.

I just happened to go with the unstable code for an install (had read where they announced that it was released - they just were not real clear that it was not the stable branch in their announcement). The individual that did that promised that they WOULD put more emphasis of the unstable branch release info so nobody would get confused.

Being on the cutting edge can sometimes cause you to bleed.

 

[Floren]

Oh, you and I both know that there is the stable branch of nginx and the unstable branch of code.

There is no such thing as "unstable" in Nginx, they have 3 branches: mainline, stable and legacy.
The mainline is not considered unstable, but rather a branch where they deploy new features to be tested by community, kind of like Fedora vs. Red Hat. I always ran the mainline since 2006, in fact AXIVO rpms have been always mainline too.

 

[TPerry]

There is no such thing as "unstable" in Nginx, they have 3 branches: mainline, stable and legacy.
The mainline is not considered unstable, but rather a branch where they deploy new features to be tested by community, kind of like Fedora vs. Red Hat. I always ran the mainline since 2006, in fact AXIVO rpms have been always mainline too.

Just because they call it something else doesn't make it something else. It's either a stable branch or an unstable/developmental-test branch.

Test = unstable for me. If it isn't the stable branch then it's the the opposite (unless it's legacy and who wants that). Problem with running cutting edge is you are either
A) always patching the source (unless using GIT)
B) running broken software

What they do is no different than what OpenLiteSpeed is doing. They have their stable branch and then their unstable - which is for use by folks to help find the bugs that they miss (and I found a few good ones).

 

[Floren]

@Tracy Perry, go ahead and contact the Nginx developers. Ask them if they consider the mainline as "unstable". You will not find anywhere on their site that word, what they do is TOTALLY DIFFERENT than what OpenLiteSpeed is doing. Trust me, each mainline release goes through extreme testing QA before is released to public. Not to mention large companies like Automattic etc. who help testing internally. Again, mainline means a branch with new features not available into stable release. You should NOT assume things, here it is a note from one of the developers... but is best you contact them directly so they will destroy all your theories about "unstable" versions in Nginx.