Best Server OS for Someone That Does not Want to Touch a Shell on a Regular Basis?

[Pierre-Luc Drouin]

Hi,

so I have a friend who is looking for the best OS for a web server, that
allows to configure services (I guess HTTP, PHP, MySQL and web content)
and do the OS maintenance (OS & package updates, firewall configuration)
without having to touch a shell. I was wondering if something like
PC-BSD + CPanel would be the way to go. Would there be other BSD-based
alternatives? I always do upgrades and configure services through the
shell and I am not aware too much about the GUI alternatives...

Thanks!
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"

[Polytropon]

On Sun, 04 Sep 2011 23:47:03 -0400, Pierre-Luc Drouin wrote:
> Hi,
>
> so I have a friend who is looking for the best OS for a web server, that
> allows to configure services (I guess HTTP, PHP, MySQL and web content)
> and do the OS maintenance (OS & package updates, firewall configuration)
> without having to touch a shell. I was wondering if something like
> PC-BSD + CPanel would be the way to go. Would there be other BSD-based
> alternatives? I always do upgrades and configure services through the
> shell and I am not aware too much about the GUI alternatives...

There are webbased configuration tools that run on common
service combinations (like Apache + MySQL + PHP) that can
be installed. However _installing_ them requires a skilled
person who is able to administrate a server, which in turn
traditionally implies the ability to use the command line,
even if it's just for that "abstraction job".

FreeBSD can be the OS running such a combination.

PC-BSD primarily aims at desktop usage, so for example it
defaults to KDE, office applications, multimedia stuff and
all the things you traditionally won't want on a server.

Software solutions that come to mind are CPanel or WebMin.
Maybe there are others? I'm not sure as I void those mostly
inflexible, error-prone, overcomplicated and dangerous
piles of bloat whenever possible. :-)

For managing installed applications (ports), there are
KDE tools for that (at least _have been_ in the past,
not sure if they are still being maintained). The system
cannot be updated by a GUI tool (why should it?), but
it should be a job of max. 30 minutes to create a Tcl/Tk
GUI wrapper for those things. And firewall configuration:
I'm quite sure PC-BSD has something for that, except that
it probably won't give you the flexibility to automatically
change firewall rules depending on different kinds of
attacks the server will encounter.

Please keep in mind: If you're running a web server, you're
part of the target group of thousands of "villains" across
the Internet who will happily exploit any weakness you are
presenting to them, depending on the services and software
you run.

What's possible to run will also depend on what kind of
server you have. For example if you run a server without
any GPU, but PC-BSD depends on hardware-accellerated 3D
graphics for managing the firewall, then... you know. :-)

There still is a question that your friend should give an
answer to himself: Wouldn't it be worth investing in basic
UNIX skills and command line operations to gain knowledge
and experience to professionally administer a server instead
of relying on abstracted layers of abstracted abstractions
that GUIs provide here, maybe paying with speed and security
loss?

It's like driving a car; you _can_ pay a driver to drive
your car all the time, but maybe you should consider to learn
how to drive yourself. :-)



--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"

[Pierre-Luc Drouin]

On 09/05/2011 08:31 AM, Polytropon wrote:

> On Sun, 04 Sep 2011 23:47:03 -0400, Pierre-Luc Drouin wrote:
>> Hi,
>>
>> so I have a friend who is looking for the best OS for a web server, that
>> allows to configure services (I guess HTTP, PHP, MySQL and web content)
>> and do the OS maintenance (OS&  package updates, firewall configuration)
>> without having to touch a shell. I was wondering if something like
>> PC-BSD + CPanel would be the way to go. Would there be other BSD-based
>> alternatives? I always do upgrades and configure services through the
>> shell and I am not aware too much about the GUI alternatives...
> There are webbased configuration tools that run on common
> service combinations (like Apache + MySQL + PHP) that can
> be installed. However _installing_ them requires a skilled
> person who is able to administrate a server, which in turn
> traditionally implies the ability to use the command line,
> even if it's just for that "abstraction job".

Well, this part is not an issue, as he will not be the one doing the
initial install of the system
> FreeBSD can be the OS running such a combination.
>
> PC-BSD primarily aims at desktop usage, so for example it
> defaults to KDE, office applications, multimedia stuff and
> all the things you traditionally won't want on a server.

But all these can be removed quite easily I guess...
> Software solutions that come to mind are CPanel or WebMin.
> Maybe there are others? I'm not sure as I void those mostly
> inflexible, error-prone, overcomplicated and dangerous
> piles of bloat whenever possible. :-)
How much security risk do these represent compared to using a Windows
server?
> For managing installed applications (ports), there are
> KDE tools for that (at least _have been_ in the past,
> not sure if they are still being maintained).
Do the PC-BSD package management tools still require KDE? I though they
were removing this dependency?

> The system
> cannot be updated by a GUI tool (why should it?), but
> it should be a job of max. 30 minutes to create a Tcl/Tk
> GUI wrapper for those things.

Can PC-BSD OS be updated through a gui?

>   And firewall configuration:
> I'm quite sure PC-BSD has something for that, except that
> it probably won't give you the flexibility to automatically
> change firewall rules depending on different kinds of
> attacks the server will encounter.
>
> Please keep in mind: If you're running a web server, you're
> part of the target group of thousands of "villains" across
> the Internet who will happily exploit any weakness you are
> presenting to them, depending on the services and software
> you run.
>
> What's possible to run will also depend on what kind of
> server you have. For example if you run a server without
> any GPU, but PC-BSD depends on hardware-accellerated 3D
> graphics for managing the firewall, then... you know. :-)
>
> There still is a question that your friend should give an
> answer to himself: Wouldn't it be worth investing in basic
> UNIX skills and command line operations to gain knowledge
> and experience to professionally administer a server instead
> of relying on abstracted layers of abstracted abstractions
> that GUIs provide here, maybe paying with speed and security
> loss?

Well, I know that. I can try convincing him...

Thanks!
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"

[Polytropon]

On Mon, 05 Sep 2011 09:18:21 -0400, Pierre-Luc Drouin wrote:

> On 09/05/2011 08:31 AM, Polytropon wrote:
> > On Sun, 04 Sep 2011 23:47:03 -0400, Pierre-Luc Drouin wrote:
> >> Hi,
> >>
> >> so I have a friend who is looking for the best OS for a web server, that
> >> allows to configure services (I guess HTTP, PHP, MySQL and web content)
> >> and do the OS maintenance (OS&  package updates, firewall configuration)
> >> without having to touch a shell. I was wondering if something like
> >> PC-BSD + CPanel would be the way to go. Would there be other BSD-based
> >> alternatives? I always do upgrades and configure services through the
> >> shell and I am not aware too much about the GUI alternatives...
> > There are webbased configuration tools that run on common
> > service combinations (like Apache + MySQL + PHP) that can
> > be installed. However _installing_ them requires a skilled
> > person who is able to administrate a server, which in turn
> > traditionally implies the ability to use the command line,
> > even if it's just for that "abstraction job".
>
> Well, this part is not an issue, as he will not be the one doing the
> initial install of the system

Okay, in this case FreeBSD can provide an excellent OS
for that purpose.



> > PC-BSD primarily aims at desktop usage, so for example it
> > defaults to KDE, office applications, multimedia stuff and
> > all the things you traditionally won't want on a server.
>
> But all these can be removed quite easily I guess...

I'm not sure about that as those are essential parts of
that FreeBSD derivate. It's like you would say to intend
to strip all GUI components from "Windows"... :-)

However, I think it would be much easier to start with
a FreeBSD install and then add those tools you want. I
assume this will consume less time (and will be less
complicated as you're not about to break something
unintendedly).



> > Software solutions that come to mind are CPanel or WebMin.
> > Maybe there are others? I'm not sure as I void those mostly
> > inflexible, error-prone, overcomplicated and dangerous
> > piles of bloat whenever possible. :-)
> How much security risk do these represent compared to using a Windows
> server?

What's a "'Windows' server"?

Really, I've not come to the conclusion that "Windows" is
to be used on _any_ servers, and as I'm not a "Windows"
person, I'm the wrong one to ask for details here.

>From my own experiences in dealing with the _problems_
"Windows" servers traditionally impose on a network
(consisting of UNIX and Linux primarily) that those who
have to administer those "Windows" boxes are either in
constant trouble (fixing things here and there, rebooting),
or just don't care (which often turns their systems into
targets for spammers, botnets and all the other unwanted
stuff that increases your costs).

The main problem of GUI in general is that it _might_
remove control you want, because it basically maps just
a subset of possibilities to a "point & grunt" interface.
A SUBset - this means that you can encounter a case where
you need something, but it can't be achieved per GUI
interaction.

Oh, that's can also be a downside: With GUI, you are tied
to interactive management. You cannot script a GUI thing,
you can't automate things. You have to do them yourself,
in a linear way.

Depending on _what_ you want to do, this should be considered
in making an educated choice.



> > For managing installed applications (ports), there are
> > KDE tools for that (at least _have been_ in the past,
> > not sure if they are still being maintained).
> Do the PC-BSD package management tools still require KDE? I though they
> were removing this dependency?

I also thought there would be a tool to manage PBIs from
the command line. However, you're free to use the standard
FreeBSD installation methods on FreeBSD, which are: binary
packages (pkg_add -r), ports subsystem and ports management
(like portmaster, portmanager, portupgrade).



> > The system
> > cannot be updated by a GUI tool (why should it?), but
> > it should be a job of max. 30 minutes to create a Tcl/Tk
> > GUI wrapper for those things.
>
> Can PC-BSD OS be updated through a gui?

Yes. They do updating per PBI, i. e. you download something
using a web browser (ouch!) and then "push da button". In
some regards, this is comparable to how Linux manages the
"system" (as it makes no difference between "the operating
system" and "installed 3rd party software", as _all_ of them
are packages, managed by the system's package installer tool).
Furthermore I assume there will be an automated notification.

So if you chosse to run PC-BSD, you encounter a typical
strength of FreeBSD (as a multi-functional OS): You end
up with a desktop system that exposes server functionality
(in your case: web server with PHP and MySQL), and that's
a completely valid approach, even though it _might_ cause
problems later on, as depending on GUI tools can lead you
to a point where functionality you need is dropped from
the "GUI abstraction layer" and you _have to_ deal with
the CLI in order to keep things running.

But time will tell you if this will happen, and how.




--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"

[Pierre-Luc Drouin]

I just took a look at PBDir and the choice of PBIs for server-related
softwares seems to be rather limited. They have a PBI for Apache, but I
could not even find one for PHP... To me it seems that if not all the
required softwares are available through PBI, it would be better to drop
the whole PBI idea all together and fall back to the FreeBSD
port/package system. But to go with the FreeBSD route, I will need to
convince my friend of using the command line at least to update the
packages and the OS. I am not sure if he will enjoy the usage of tools
such as mergemaster, given that this requires to have a good idea of
what is going on in the config files. This might make an OS like Ubuntu
easier to use for my friend, although this is probably not the most
stable and secure OS for a server. It might be a necessary compromise in
this case though...
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"

[Polytropon]

On Mon, 05 Sep 2011 09:59:23 -0400, Pierre-Luc Drouin wrote:
> I just took a look at PBDir and the choice of PBIs for server-related
> softwares seems to be rather limited.

Okay, that's understandable, as servers are not their
main target. In fact, what do you need a GUI for on a
server? - This is a typical question in such a setting,
even though it is _possible_ to run a desktop with
server functionality.



> They have a PBI for Apache, but I
> could not even find one for PHP... To me it seems that if not all the
> required softwares are available through PBI, it would be better to drop
> the whole PBI idea all together and fall back to the FreeBSD
> port/package system.

Yes, I would agree with that. PBIs are primarily used to
distribute desktop-oriented software in a fashion that
a web browser is involved in obtaining them (instead of
using comfortable tools like pkg_add or portmaster).



> But to go with the FreeBSD route, I will need to
> convince my friend of using the command line at least to update the
> packages and the OS.

That's not a problem! You can easily write a short script
that performs the required steps. Really, what's so hard
about entering "portmaster -a"? I know it's a bit more
complicated to update the system (i. e. following the
11 steps in /usr/src/Makefile), but it's also possible
to make a Tcl/Tk GUI wrapper for that. In fact, it's
even possible to make a desktop icon for a shell script
that performs the required steps.

Oh, and just in case you do not intend to update from
source, why not use freebsd-update? It's _very_ easy
to use, and it can also be included in a GUI wrapper.

That would be the way I'd suggest: Install desired
packages first with portmaster, keep the system up
to date using both portmaster (for ports) and freebsd-update
for the OS.

(Of course you can choose a different port management
tool if you like.)



> I am not sure if he will enjoy the usage of tools
> such as mergemaster, given that this requires to have a good idea of
> what is going on in the config files.

The person who runs and administers a server is supposed to
know what's going on on the system he is responsible for.
You may call me old-fashioned for having such an opinion. :-)

But as I mentioned above, you can omit mergemaster use if
you keep using the -RELEASE-pX OS branch and use the binary
method of freebsd-update. It's as simple as "pkg_add -r".



> This might make an OS like Ubuntu
> easier to use for my friend, although this is probably not the most
> stable and secure OS for a server.

There _are_ Linux distributions that provide a lot of GUI
even for their server systems. I'm not sure which one it
was... Red Hat maybe? Or SuSE? Their server and PC systems
are designed to be "compatible" (in terms of GUI presented
to the user and the administrator).

Regarding Ubuntu, it's a quite nice desktop Linux, but I'm
not sure how well it does _perform_ (see: performance) on
a server. Maybe you can do some research on Linux server
operating systems that emphasize an administration GUI?
As I said, I think SuSE or Red Hat has something like that.



--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"

[Pierre-Luc Drouin]

How well does it work to use binary packages only to maintain a FreeBSD
web server in general (I am thinking of package availability, but also
and in particular as a quasi-automated updating tool)? I noticed that in
the past few years, updating softwares through ports has been requiring
more user intervention, due to the way some dependencies are being
updated from one version to the next. Would using binary packages allow
to avoid more such user intervention?

Thanks
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"

[Dick Hoogendijk-2]

If you really want. GUI based server, go for a Windows one. It will cost you but security has improved. I would never do it though but I manage my server with shell tools. I love the easiness of textbased config files ;)

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"

[Polytropon]

On Mon, 05 Sep 2011 10:20:22 -0400, Pierre-Luc Drouin wrote:
> How well does it work to use binary packages only to maintain a FreeBSD
> web server in general (I am thinking of package availability, but also
> and in particular as a quasi-automated updating tool)?

Quite well - as long as you're satisfied with the default
building options. You know that a binary package is a port,
compiled with the default set of options. This is okay in
most cases, but there may be situations where you explicitely
need to enable or disable a certain feature at compile time.

You also may encounter a situation where _no_ package is
available for a port (e. g. too many options, or licensing
restrictions).

This can be solved by portmaster which has an option to
go through all interactive configuration screens _before_
starting any action. Those settings can be saved for the
next update run.

The portmaster program itself can be instructed to _use_
binary packages (just as pkg_add -r would do) with the -P
and -PP options. In this case, binary packages will be
used as long as possible, and only those ports that
require building (as no package exists) will be compiled.
See "man portmaster" for details.

This is a good approach in combination with freebsd-update.
I have used that concept on some servers myself (especially
on smaller ones with low resources where compiling would
be too problematic).



> I noticed that in
> the past few years, updating softwares through ports has been requiring
> more user intervention, due to the way some dependencies are being
> updated from one version to the next. Would using binary packages allow
> to avoid more such user intervention?

Yes. All dependencies would be incorporated automatically.
Only ports without equivalent package that additionally have
OPTIONS to set would invoke a configuration screen, and this
screen would have to be dealt with only in the first run of
the updating process.

There are also options for portmaster that can be used to
control program behaviour in case of problems (e. g. some
package not found, conflicting ports, versioning problem,
or port marked "broken").

Those solutions can also easily be scripted, e. g. check
one a week for possible updates and get the packages, but
do not install them automatically (which can be a security
requirement). If the list is approved, the updates will
be installed during night, creating a "fallback copy" just
in case something went wrong (e. g. malfunctioning new
software). Reports can be generated automatically and mailed
to the system administrator.

I would also suggest to frequently check the mailing lists
of the software in use for bugs and security updates that
might be interesting in terms of system security. This sould
be done for any "major server software" (Apache, PHP, MySQL
and the services utilizing those software, whatever you
want to run on the server).



--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"

[Pierre-Luc Drouin]

>> I noticed that in
>> the past few years, updating softwares through ports has been requiring
>> more user intervention, due to the way some dependencies are being
>> updated from one version to the next. Would using binary packages allow
>> to avoid more such user intervention?
> Yes. All dependencies would be incorporated automatically.
> Only ports without equivalent package that additionally have
> OPTIONS to set would invoke a configuration screen, and this
> screen would have to be dealt with only in the first run of
> the updating process.
>
> There are also options for portmaster that can be used to
> control program behaviour in case of problems (e. g. some
> package not found, conflicting ports, versioning problem,
> or port marked "broken").
>

So, what I was referring to in particulars was special updates like this:
20110517:
   AFFECTS: users of lang/perl*
   AUTHOR: [hidden email]

   lang/perl5.14 is out. If you want to switch to it from, for example
   lang/perl5.12, that is:

   Portupgrade users:
     0) Fix pkgdb.db (for safety):
         pkgdb -Ff

     1) Reinstall new version of Perl (5.14):
         env DISABLE_CONFLICTS=1 portupgrade -o lang/perl5.14 -f
perl-5.12.\*

     2) Reinstall everything that depends on Perl:
         portupgrade -fr perl

So you are saying that this type of special interventions is not
necessary when using only binary packages, right?

Thanks!
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"

[Jerome Herman]

Le 05/09/2011 05:47, Pierre-Luc Drouin a écrit :

> Hi,
>
> so I have a friend who is looking for the best OS for a web server,
> that allows to configure services (I guess HTTP, PHP, MySQL and web
> content) and do the OS maintenance (OS & package updates, firewall
> configuration) without having to touch a shell. I was wondering if
> something like PC-BSD + CPanel would be the way to go. Would there be
> other BSD-based alternatives? I always do upgrades and configure
> services through the shell and I am not aware too much about the GUI
> alternatives...
>
> Thanks!
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "[hidden email]"

Hello,

If your friend prefer to use a GUI rather than command line interface,
why not. But I  am a little affraid that is real goal is to avoid
reading the documentation, and keeping up to date with good practices
and security alerts.

Truly it doesn't matter what OS you are using and what use you make of
it, when your server is exposed to the internet, you must read the doc
and check for security alerts.


If it is what your friend is trying to avoid, then I would strongly
advise him to subscribe to a fully maintained platform, software as a
service, or a mutualized box. Any other option will lead to a disaster.

On the other hand, if your friend is willing to accept a bit of shell
here and there, and a good deal of doc reading, I would recommand using
FreeBSD or Debian as the underlying server (lowest maintenance/usage
ratio I know). If you go for FreeBSD I would advise to use this doc
http://www.bsdguides.org/guides/freebsd/security/harden.php

The only easy to configure and to maintain web server I know is Cherokee
(http://www.cherokee-project.com/ ). The web admin is quite easy to use,
and a lot more intuitive than Apache.


Jerome Herman.


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"

[Polytropon]

On Mon, 05 Sep 2011 10:50:19 -0400, Pierre-Luc Drouin wrote:

>
> >> I noticed that in
> >> the past few years, updating softwares through ports has been requiring
> >> more user intervention, due to the way some dependencies are being
> >> updated from one version to the next. Would using binary packages allow
> >> to avoid more such user intervention?
> > Yes. All dependencies would be incorporated automatically.
> > Only ports without equivalent package that additionally have
> > OPTIONS to set would invoke a configuration screen, and this
> > screen would have to be dealt with only in the first run of
> > the updating process.
> >
> > There are also options for portmaster that can be used to
> > control program behaviour in case of problems (e. g. some
> > package not found, conflicting ports, versioning problem,
> > or port marked "broken").
> >
> So, what I was referring to in particulars was special updates like this:
> 20110517:
>    AFFECTS: users of lang/perl*
>    AUTHOR: [hidden email]
>
>    lang/perl5.14 is out. If you want to switch to it from, for example
>    lang/perl5.12, that is:
>
>    Portupgrade users:
>      0) Fix pkgdb.db (for safety):
>          pkgdb -Ff
>
>      1) Reinstall new version of Perl (5.14):
>          env DISABLE_CONFLICTS=1 portupgrade -o lang/perl5.14 -f
> perl-5.12.\*
>
>      2) Reinstall everything that depends on Perl:
>          portupgrade -fr perl
>
> So you are saying that this type of special interventions is not
> necessary when using only binary packages, right?

Erm... no, or basically yes. :-)

First of all, the example here refers to portupgrade, not
to portmaster.

The DISABLE_CONFLICTS variable is only required where
something is built from source. By using packages, you
can even _force_ installation of (maybe conflicting)
packages, implying of course that this may cause damage.

In _worst_ cases, there's the option to forcedly deinstall
packages and then re-install them (in a newer version),
this may be useful when the upgrade path is too much
trouble.

Coming back to that example: If you order portmaster to
upgrade perl, you will traditionally also upgrade all
ports depending on it. And if this is possible via
packages (-P, -PP), it will "reconstruct" the dependencies
properly so all programs can use the new perl version.

However, as I've turned into a "compile guy" due to
sufficient hardware, I usually use source-based updates
when needed. I don't update my home system very often,
because I'd like to keep it in a functional state. :-)

So I've not come across that particular update yet, as
I still have perl-threaded-5.10.1_4 installed, and there's
nothing here that requires 5.12 or 5.14.



When you choose to use portupgrade instead of portmaster,
it's a good choice to always run "pkgdb -aF" before and
after anything you do (e. g. also "around" a pkg_add -r
command). I've been using portupgrade in the past, but
today I prefer "just ports" (home) and portmaster (work).



--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"

[Outback Dingo-2]

FreeBSD

On Mon, Sep 5, 2011 at 8:31 AM, Polytropon <[hidden email]> wrote:

> On Sun, 04 Sep 2011 23:47:03 -0400, Pierre-Luc Drouin wrote:
>> Hi,
>>
>> so I have a friend who is looking for the best OS for a web server, that
>> allows to configure services (I guess HTTP, PHP, MySQL and web content)
>> and do the OS maintenance (OS & package updates, firewall configuration)
>> without having to touch a shell. I was wondering if something like
>> PC-BSD + CPanel would be the way to go. Would there be other BSD-based
>> alternatives? I always do upgrades and configure services through the
>> shell and I am not aware too much about the GUI alternatives...
>

FreeBSD and ISPCP do wonders and its not bloated like cpanel, source
available and it just works, webmin is junk, and cpanel is resource
intensive

> There are webbased configuration tools that run on common
> service combinations (like Apache + MySQL + PHP) that can
> be installed. However _installing_ them requires a skilled
> person who is able to administrate a server, which in turn
> traditionally implies the ability to use the command line,
> even if it's just for that "abstraction job".
>
> FreeBSD can be the OS running such a combination.
>
> PC-BSD primarily aims at desktop usage, so for example it
> defaults to KDE, office applications, multimedia stuff and
> all the things you traditionally won't want on a server.
>
> Software solutions that come to mind are CPanel or WebMin.
> Maybe there are others? I'm not sure as I void those mostly
> inflexible, error-prone, overcomplicated and dangerous
> piles of bloat whenever possible. :-)
>
> For managing installed applications (ports), there are
> KDE tools for that (at least _have been_ in the past,
> not sure if they are still being maintained). The system
> cannot be updated by a GUI tool (why should it?), but
> it should be a job of max. 30 minutes to create a Tcl/Tk
> GUI wrapper for those things. And firewall configuration:
> I'm quite sure PC-BSD has something for that, except that
> it probably won't give you the flexibility to automatically
> change firewall rules depending on different kinds of
> attacks the server will encounter.
>
> Please keep in mind: If you're running a web server, you're
> part of the target group of thousands of "villains" across
> the Internet who will happily exploit any weakness you are
> presenting to them, depending on the services and software
> you run.
>
> What's possible to run will also depend on what kind of
> server you have. For example if you run a server without
> any GPU, but PC-BSD depends on hardware-accellerated 3D
> graphics for managing the firewall, then... you know. :-)
>
> There still is a question that your friend should give an
> answer to himself: Wouldn't it be worth investing in basic
> UNIX skills and command line operations to gain knowledge
> and experience to professionally administer a server instead
> of relying on abstracted layers of abstracted abstractions
> that GUIs provide here, maybe paying with speed and security
> loss?
>
> It's like driving a car; you _can_ pay a driver to drive
> your car all the time, but maybe you should consider to learn
> how to drive yourself. :-)
>
>
>
> --
> Polytropon
> Magdeburg, Germany
> Happy FreeBSD user since 4.0
> Andra moi ennepe, Mousa, ...
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "[hidden email]"
>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[hidden email]"

[Frank Shute-2]

On Mon, Sep 05, 2011 at 04:36:23PM +0200, Polytropon wrote:

>
> On Mon, 05 Sep 2011 10:20:22 -0400, Pierre-Luc Drouin wrote:
> > How well does it work to use binary packages only to maintain a FreeBSD
> > web server in general (I am thinking of package availability, but also
> > and in particular as a quasi-automated updating tool)?
>
> Quite well - as long as you're satisfied with the default
> building options. You know that a binary package is a port,
> compiled with the default set of options. This is okay in
> most cases, but there may be situations where you explicitely
> need to enable or disable a certain feature at compile time.
>
> You also may encounter a situation where _no_ package is
> available for a port (e. g. too many options, or licensing
> restrictions).
>
> This can be solved by portmaster which has an option to
> go through all interactive configuration screens _before_
> starting any action. Those settings can be saved for the
> next update run.
>
> The portmaster program itself can be instructed to _use_
> binary packages (just as pkg_add -r would do) with the -P
> and -PP options. In this case, binary packages will be
> used as long as possible, and only those ports that
> require building (as no package exists) will be compiled.
> See "man portmaster" for details.
>
> This is a good approach in combination with freebsd-update.
> I have used that concept on some servers myself (especially
> on smaller ones with low resources where compiling would
> be too problematic).
>
>
>
> > I noticed that in
> > the past few years, updating softwares through ports has been requiring
> > more user intervention, due to the way some dependencies are being
> > updated from one version to the next. Would using binary packages allow
> > to avoid more such user intervention?
>
> Yes. All dependencies would be incorporated automatically.
> Only ports without equivalent package that additionally have
> OPTIONS to set would invoke a configuration screen, and this
> screen would have to be dealt with only in the first run of
> the updating process.
>
> There are also options for portmaster that can be used to
> control program behaviour in case of problems (e. g. some
> package not found, conflicting ports, versioning problem,
> or port marked "broken").
>
> Those solutions can also easily be scripted, e. g. check
> one a week for possible updates and get the packages, but
> do not install them automatically (which can be a security
> requirement). If the list is approved, the updates will
> be installed during night, creating a "fallback copy" just
> in case something went wrong (e. g. malfunctioning new
> software). Reports can be generated automatically and mailed
> to the system administrator.
>
> I would also suggest to frequently check the mailing lists
> of the software in use for bugs and security updates that
> might be interesting in terms of system security. This sould
> be done for any "major server software" (Apache, PHP, MySQL
> and the services utilizing those software, whatever you
> want to run on the server).
>

I'd recommend installing ports-mgmt/portaudit to keep an eye out on
any vulnerabilities that require an update of the ports/packages.

Personally, I'd go for ports rather than packages.

As long as your friend reads /usr/ports/UPDATING and he uses either
portupgrade or portmaster, he shouldn't go too far wrong.

Also couldn't your friend give you a key for his server so that you
can ssh into it and fix things if it goes wrong?


Regards,

--

 Frank

 Contact info: http://www.shute.org.uk/misc/contact.html