Re: projects to better support FreeBSD sysadmins

2015-01-15 Thread Craig Rodrigues
On Wed, Jan 14, 2015 at 9:48 PM, Steve Rikli  wrote:

>
> Instead, I think there needs to be more focus on the parts of the OS
> automated installation which are FreeBSD-specific and different from
> the Linux Kickstart equivalents; e.g. just off the top of my head:
>
> - how is the FreeBSD pxeboot loader different from Linux?  E.g.
>   what args/options will it accept?  Can it play nicely with
>   PXElinux these days?  Example pxe.cfg files?  What if you need
>   to have multiple FreeBSD versions and architectures Kickstarted
>   from the same server?
>
> - what is the modern FreeBSD equivalent of a Linux Kickstart
>   ks.cfg file, if any?
>
> - how does one script/automate the postinstall configuration with
>   sysinstall or PC-BSD's installer or ???
>
> - likewise for preinstall steps, if applicable (Linux Kickstart
>   has sections for both in the kickstart config file) e.g. for
>   disk partitioning or other early actions during an automated
>   OS install
>

I just found out about something today.
Can you review this work by Google Summer of Code student Kamil Czekirda
and see how functional it is compared to Linux kickstart:
https://lists.freebsd.org/pipermail/freebsd-current/2015-January/053994.html

If this work fits the needs, then maybe we can focus on getting it into
the FreeBSD tree, improving the docs, and making sure that web searches
for "FreeBSD kickstart" show this stuff.


>
> Whereas for better or worse, Linux Kickstart and PXElinux (or SYSlinux
> etc.) seems to be the defacto standard for typical OS deployments, until
> you get to cloud-y things and cloning VMs and whatnot.  But even in
> cloud/vm areas, you still may want to Kickstart at least the 1st
> instance, right?
>

I definitely need to bootstrap/kickstart the first initial instance of
VM's for things I am working on.  I think other people need to do the same
thing also.

--
Craig
___
freebsd-advocacy@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy
To unsubscribe, send any mail to "freebsd-advocacy-unsubscr...@freebsd.org"


Re: projects to better support FreeBSD sysadmins

2015-01-14 Thread Steve Rikli
On Wed, Jan 14, 2015 at 09:28:07AM -0800, Craig Rodrigues wrote:
> 
> kickstart and freebsd-update are just two examples, found very quickly
> after trying to set this
> stuff up.  freebsd-update has been around since 2006.  The problem
> I mentioned and workarounds have been mentioned on the web since then.
> To go back to Royce's original posting, I am seeing that there is a
> definite disconnect between developers who work on the source tree, and
> people
> who are deploying FreeBSD in modern datacenter and cloud environments.
> 
> I'm actually not the only one who has run into these types of problems.
> I've talked to a friend in a company making a product based on FreeBSD,
> who has run into similar problems when trying to do kickstart and mass
> deployment of FreeBSD nodes.  If you are willing to code your own stuff up,
> it is doable, but things are definitely not as well documented and turnkey
> as the Linux equivalet solutions.

I think Craig's comments capture my own experience with FreeBSD Kickstart
pretty well.

I setup Kickstart/Jumpstart for FreeBSD 6.* long ago at $WORK, and it
was a fair amount of effort putting all the pieces together from various
docs and websearching, plus some scripting on my own for postinstall
(which is fine, and expected -- not unlike Linux).

The end results were functional, but it wasn't as flexible or easy to do
as Linux Kickstart with PXElinux.  IIRC I ended up having to recompile
the FreeBSD pxeboot loader, since it hardcoded "/pxeroot" as the NFS
root path, and didn't support TFTP (I think); I had to do that for all
versions and architectures of FreeBSD we ran at the time -- so it had a
relatively high "start-up cost" to get a new/additional version going,
compared to a new version of Linux CentOS or what have you.

Nowdays I'm not sure where to start with modern FreeBSD 9 or 10.  I keep
an eye out for sysinstall- and PXE-related activity in modern FreeBSD,
and I gather there have been changes in those areas, but I confess I
haven't pursued any of them yet.

For my own admittedly selfish needs, in the context of this thread
I'm less interested in Puppet and the other configuration management
orchestration schemes -- there are already howto recipes and docs and
other help resources for those, and I don't think FreeBSD needs to
reinvent the wheel to get FreeBSD-flavored docs.

Nor do I think we need another FreeBSD howto on setting up an NFS, DHCP,
TFTP, HTTP, etc. server, e.g. to provide the OS images to Kickstart --
again, documentation for that already exists, and even the Linux docs
are not hard to adapt to FreeBSD.  Plus the Ports Collection is great
for whatever services don't come along natively with the base FreeBSD.

Instead, I think there needs to be more focus on the parts of the OS
automated installation which are FreeBSD-specific and different from
the Linux Kickstart equivalents; e.g. just off the top of my head:

- how is the FreeBSD pxeboot loader different from Linux?  E.g.
  what args/options will it accept?  Can it play nicely with
  PXElinux these days?  Example pxe.cfg files?  What if you need
  to have multiple FreeBSD versions and architectures Kickstarted
  from the same server?

- what is the modern FreeBSD equivalent of a Linux Kickstart
  ks.cfg file, if any?

- how does one script/automate the postinstall configuration with
  sysinstall or PC-BSD's installer or ???

- likewise for preinstall steps, if applicable (Linux Kickstart
  has sections for both in the kickstart config file) e.g. for
  disk partitioning or other early actions during an automated
  OS install

As others have mentioned in this thread, the RedHat/CentOS et al docs
for those areas are pretty good and pretty easily found.  I'd love to
see something similar for FreeBSD instead of my very old cobbled-
together notes which probably aren't applicable anymore.

Maybe I'm wrong (always a distinct possibility :-) ) but it seems to me
that clouds and VMs already have their own deployment mechanisms (the AWS
Store or VMware templates and clones etc.), so again that's an area where
FreeBSD maybe shouldn't spend a lot of resources to reinvent wheels and
documentation.

Whereas for better or worse, Linux Kickstart and PXElinux (or SYSlinux
etc.) seems to be the defacto standard for typical OS deployments, until
you get to cloud-y things and cloning VMs and whatnot.  But even in
cloud/vm areas, you still may want to Kickstart at least the 1st
instance, right?

In any case, thanks for having the conversation.

Cheers,
sr.
___
freebsd-advocacy@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy
To unsubscribe, send any mail to "freebsd-advocacy-unsubscr...@freebsd.org"


Re: projects to better support FreeBSD sysadmins

2015-01-14 Thread Craig Rodrigues
On Tue, Jan 13, 2015 at 7:53 PM, Hunter Satterwhite <
hsatterwh...@webassign.net> wrote:

> Thanks for providing more detail Craig.
>
> Fair enough, but these two items are minor at best and I don't feel like
> they do much in the way of supporting your previous claim. While I do
> wholeheartedly agree with the fact that freebsd-update should "just work"
> it's still easy to work around.
>

kickstart and freebsd-update are just two examples, found very quickly
after trying to set this
stuff up.  freebsd-update has been around since 2006.  The problem
I mentioned and workarounds have been mentioned on the web since then.
To go back to Royce's original posting, I am seeing that there is a
definite disconnect between developers who work on the source tree, and
people
who are deploying FreeBSD in modern datacenter and cloud environments.

I'm actually not the only one who has run into these types of problems.
I've talked to a friend in a company making a product based on FreeBSD,
who has run into similar problems when trying to do kickstart and mass
deployment of FreeBSD nodes.  If you are willing to code your own stuff up,
it is doable, but things are definitely not as well documented and turnkey
as the Linux equivalet solutions.




>
> To automate the installation of FreeBSD without the use of any other
> 3rd-party tools you would write your own shell script for bsdinstall. It's
> pretty straight forward and easy to do. However, I'd argue that if you want
> to operate at the scale you keep referring to and do it full life cycle,
> then you're likely not going to be doing this. Instead you'll be using
> tools, like Foreman and Puppet, which will make provisioning systems a
> cinch.
>


For the http://jenkins.freebsd.org cluster, I quickly came to the conclusion
that you have described.  I put out a Call for Help for some devops
assistance:

https://lists.freebsd.org/pipermail/freebsd-current/2014-December/053584.html

and got one volunteer from Ahmed Kamal, a devops expert who works for
a company specializing in cloud/devops ( http://www.cloud9ers.com ):

https://lists.freebsd.org/pipermail/freebsd-testing/2015-January/000723.html

Ahmed is new to FreeBSD, but he definitely knows his stuff with devops
and cloud, and has started providing code and scripts to help:

https://github.com/freebsd/freebsd-ci/commits/master

Any issues that Ahmed is finding in FreeBSD itself (whether it is src,
ports, or docs), I am trying to push fixes back into FreeBSD itself to
improve things
and smooth things over.



>
> FWIW, I've had both inexperienced and experienced Linux system
> administrators who want to employ the use of DevOps and have had both at
> some point and time state, "You can't do that with FreeBSD" or "FreeBSD
> makes it very difficult to do X". Each and every time they were incorrect
> and it was, because FreeBSD is not their wheel house and unfortunately they
> didn't take the time to do much research on their own. No one administrator
> can be an expert in everything, but part of what we do requires us to be
> inquisitive and investigative. Two traits that are fading fast in Linux
> administrators.
>
>
Well, like it or not, Linux (in its various distributions) has succeeded in
becoming the dominant Unix platform in the modern datacenter.  The
3rd party tools, documentation, and skillset of people who are available
for hire reflect this, and FreeBSD is an afterthought.

Anything that we can do in FreeBSD to change things in the base system,
ports, and documentation to make things easier for sysadmins, as Royce
pointed out, would be a great focus for the project and Foundation.

Having people like Ahmed, who are familiar with the Linux ways of doing
things, but are open to pointing out where FreeBSD lags behind and helping
improve things, is as good a place to start as any.

--
Craig
___
freebsd-advocacy@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy
To unsubscribe, send any mail to "freebsd-advocacy-unsubscr...@freebsd.org"


Re: projects to better support FreeBSD sysadmins

2015-01-13 Thread Royce Williams
On Tue, Jan 13, 2015 at 5:41 PM, Joshua Smith  wrote:
>> On Jan 13, 2015, at 6:14 PM, Royce Williams  wrote:
>>
>> At Craig Rodrigues' request, I'm starting a new thread here branched
>> from a freebsd-ports@ thread.  For those who want more context, the
>> original thread starts here:
>>
>> https://lists.freebsd.org/pipermail/freebsd-ports/2015-January/097462.html
>>
>> It was initially about BIND REPLACE_BASE, but branched off into
>> general sysadmin concerns that Craig wanted to respond to.
>>
>> Royce
>>
>> -- Forwarded message --
>> From: Royce Williams 
>> Date: Mon, Jan 12, 2015 at 7:10 AM
>> Subject: Re: BIND REPLACE_BASE option
>> To: ports 
>> Cc: Deb Goodkin 
>>
>> On Mon, Jan 12, 2015 at 4:08 AM, Kurt Jaeger  wrote:
>>
 No disputing that, just thinking, is FreeBSD being driven by user need,
 financial contributer need, developer need, security need, making things
 'better' or just by people wanting to make their mark in a warped sense
 of "it'll all get better"...?
>>>
>>> Probably by developer *capacity* (not need) and fire-fighting,
>>> like most IT stuff 8-(
>>
>> But like most IT stuff, resources are being asymmetrically applied to
>> the root causes of the fires.
>>
>> Read the list of projects from last quarter:

I did not intend to pick on each of these projects, though you've
responded as though I had.  Rather, I am trying to encourage the
Foundation to look at them in the aggregate, and think about other
entire families of project ideas that could be encouraged.

>> - Address Space Layout Randomization (ASLR)
>
> I would hardly consider this esoteric.

I used the phrase "relatively esoteric" on purpose.  "Esoteric" means
"intended for or likely to be understood by only a small number of
people with a specialized knowledge or interest," and "relatively"
here means relative to other broad areas of high-level FreeBSD
improvement.

I stand by the assessment.  I believe that small-shop admins would
value stable port management and other basics like my list below
before most of the projects on the list.

>> - amd64 Xen Paravirtualization
>> - bhyve
>
> The ability for FreeBSD to host VMs is definitely something that I find very 
> interesting and useful. I am a sysadmin.

My intent was not to say that these things aren't useful.  It was that
there are some other basic things that could use some attention as
well.

>> - Chelsio iSCSI Offload Support
>> - Debian GNU/kFreeBSD
>> - FreeBSD Preseed Installation (PXE)
>
> This also fits right in the making a sysadmin a life easier wheel house.

When sysadmins are afraid to upgrade ports because of a hidden cascade
of dependencies that will result in an unusable system, PXE is a great
way to recover.

What would be even better is a way to reduce the chances of that
cascade in the first place.

>> - Jenkins Continuous Integration for FreeBSD
>> - New Automounter
>
> An auto mounter that behaves more like what is in other unixes also improves 
> my life as a sysadmin.
>
>> - QEMU bsd-user-Enabled Ports Building
>> - VMWare VAAI and Microsoft ODX Acceleration in CTL
>
> Not really sysadmin focused but definitely not esoteric.

I was going to try to respond to this in some way, but I'd like to
just restate my broader point that the project has opportunities in
other kinds of areas that would make it so that more core resources
become available to work on needed improvements like this one.

>> - ZFSguru
>> - Intel GPU Driver Update
>> - SDIO Driver
>> - UEFI Boot
>
> Like it or not UEFI is the future supporting it well is not optional.

I agree.

>> - Updated vt(4) System Console
>> - Updating OpenCrypto
>> - FreeBSD on Newer ARM Boards
>
>> - FreeBSD/arm64
>> - LLDB Debugger Port
>> - LLVM Address Sanitizer (Asan)
>> - SSE Variants of libc Routines for amd64
>> - FreeBSD Python Ports
>> - GNOME/FreeBSD
>> - KDE on FreeBSD
>> - The Graphics Stack on FreeBSD
>> - Xfce
>>
>> The Foundation section also lists these items not overlapping with the above:
>>
>> - FreeBSD Journal
>> - PostgreSQL performance improvements
>> - Ongoing release process
>> - Development snapshots
>
> A better release process will likely benefit me as a sysadmin.

Agreed.

>> - VM images for releases
>
> Being able to boot the base system on the hyper visor of my choice with out 
> having to muddle through the installer is a huge time saver and a bandit of 
> sysadmin a everywhere.
>
>> - Secure Boot planning
>> - Infrastructure hardware
>> - Java licensing
>> - Summits and summit sponsorship
>> - Travel grants, tutorials, and talks
>> - New Design and Implementation book
>> - Recruitment flyers
>>
>> Are there long-term improvement projects that aren't being listed?  If
>> so, they should be.
>
> These are just projects sponsored by the foundation. I'm sure there are many 
> other developments occurring throughout the project that are not listed here 
> because they are not sponsored by the foundation.

The purpose of my message was to ask the Found

Re: projects to better support FreeBSD sysadmins

2015-01-13 Thread Hunter Satterwhite
Thanks for providing more detail Craig.

Fair enough, but these two items are minor at best and I don't feel like
they do much in the way of supporting your previous claim. While I do
wholeheartedly agree with the fact that freebsd-update should "just work"
it's still easy to work around.

To automate the installation of FreeBSD without the use of any other
3rd-party tools you would write your own shell script for bsdinstall. It's
pretty straight forward and easy to do. However, I'd argue that if you want
to operate at the scale you keep referring to and do it full life cycle,
then you're likely not going to be doing this. Instead you'll be using
tools, like Foreman and Puppet, which will make provisioning systems a
cinch.

FWIW, I've had both inexperienced and experienced Linux system
administrators who want to employ the use of DevOps and have had both at
some point and time state, "You can't do that with FreeBSD" or "FreeBSD
makes it very difficult to do X". Each and every time they were incorrect
and it was, because FreeBSD is not their wheel house and unfortunately they
didn't take the time to do much research on their own. No one administrator
can be an expert in everything, but part of what we do requires us to be
inquisitive and investigative. Two traits that are fading fast in Linux
administrators.

- Hunter

On Tue, Jan 13, 2015 at 10:30 PM, Craig Rodrigues 
wrote:

> On Tue, Jan 13, 2015 at 7:13 PM, Hunter Satterwhite <
> hsatterwh...@webassign.net> wrote:
>
>> Craig,
>>
>> Could you elaborate on these "problems"? Our data center is ~400 nodes
>> and 99% FreeBSD. We've used CFengine, we're implementing Puppet (and its
>> going great!), we use Ansible, and we also use languages such as Python,
>> Ruby, and Google's Go. Oh and not to mention we have a RESTful application
>> running on FreeBSD + node.js + MongoBD/MySQL.
>>
>> I think the project's focus is fine. Year after year we're given a
>> complete, enterprise Unix operating system and it's only getting better.
>>
>>
>
> I can point to two problems which I found today:
>
> (1)  freebsd-update doesn't work so well in an automation environment
> without a real tty:
>
>
> https://lists.freebsd.org/pipermail/freebsd-current/2015-January/053982.html
>
>   This was pointed out to me by a devops expert who is helping me with
> automation
>   for the http://jenkins.freebsd.org.
>
> (2)  documentation for doing "kickstart" installs of FreeBSD is not as
> easy to find as for Linux:
>
>
> https://lists.freebsd.org/pipermail/freebsd-current/2015-January/053970.html
>
>  This was pointed out to me by another devops person I am working with
> who is familiar
>  with setting up kickstart installs for Linux, but couldn't easily
> figure out how to do it for FreeBSD.
>
> These are very basic things and can be solved on their own,
> but I would like to see more of a focus on this kind of stuff at a project
> level, so that
> these problems don't exist in the first place, and things *just work*.
>
> For many people, the perception is that Linux is easier for devops people
> to work
> with than FreeBSD, and they can install/maintain many nodes in large cloud
> and datacenter environments
> more easily.  I have seen in two companies where hundreds of FreeBSD nodes
> were migrated to Linux,
> because the IT/devops staff found Linux worked better at large scale than
> FreeBSD in the modern datacenter.
>
> I think the FreeBSD project is improving, but we can do better.
>
> --
> Craig
>
>


-- 
Hunter Satterwhite
Systems Engineer, Technical Operations (TechOps)
___
freebsd-advocacy@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy
To unsubscribe, send any mail to "freebsd-advocacy-unsubscr...@freebsd.org"


Re: projects to better support FreeBSD sysadmins

2015-01-13 Thread Craig Rodrigues
On Tue, Jan 13, 2015 at 7:13 PM, Hunter Satterwhite <
hsatterwh...@webassign.net> wrote:

> Craig,
>
> Could you elaborate on these "problems"? Our data center is ~400 nodes and
> 99% FreeBSD. We've used CFengine, we're implementing Puppet (and its going
> great!), we use Ansible, and we also use languages such as Python, Ruby,
> and Google's Go. Oh and not to mention we have a RESTful application
> running on FreeBSD + node.js + MongoBD/MySQL.
>
> I think the project's focus is fine. Year after year we're given a
> complete, enterprise Unix operating system and it's only getting better.
>
>

I can point to two problems which I found today:

(1)  freebsd-update doesn't work so well in an automation environment
without a real tty:


https://lists.freebsd.org/pipermail/freebsd-current/2015-January/053982.html

  This was pointed out to me by a devops expert who is helping me with
automation
  for the http://jenkins.freebsd.org.

(2)  documentation for doing "kickstart" installs of FreeBSD is not as easy
to find as for Linux:


https://lists.freebsd.org/pipermail/freebsd-current/2015-January/053970.html

 This was pointed out to me by another devops person I am working with
who is familiar
 with setting up kickstart installs for Linux, but couldn't easily
figure out how to do it for FreeBSD.

These are very basic things and can be solved on their own,
but I would like to see more of a focus on this kind of stuff at a project
level, so that
these problems don't exist in the first place, and things *just work*.

For many people, the perception is that Linux is easier for devops people
to work
with than FreeBSD, and they can install/maintain many nodes in large cloud
and datacenter environments
more easily.  I have seen in two companies where hundreds of FreeBSD nodes
were migrated to Linux,
because the IT/devops staff found Linux worked better at large scale than
FreeBSD in the modern datacenter.

I think the FreeBSD project is improving, but we can do better.

--
Craig
___
freebsd-advocacy@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy
To unsubscribe, send any mail to "freebsd-advocacy-unsubscr...@freebsd.org"


Re: projects to better support FreeBSD sysadmins

2015-01-13 Thread Hunter Satterwhite
Craig,

Could you elaborate on these "problems"? Our data center is ~400 nodes and
99% FreeBSD. We've used CFengine, we're implementing Puppet (and its going
great!), we use Ansible, and we also use languages such as Python, Ruby,
and Google's Go. Oh and not to mention we have a RESTful application
running on FreeBSD + node.js + MongoBD/MySQL.

I think the project's focus is fine. Year after year we're given a
complete, enterprise Unix operating system and it's only getting better.

Best,
Hunter

On Tue, Jan 13, 2015 at 9:45 PM, Craig Rodrigues 
wrote:

> On Tue, Jan 13, 2015 at 02:14:24PM -0900, Royce Williams wrote:
> > But the overall project list needed to be rebalanced towards system
> > administration.  I request that the Foundation consider this when
> > calling for proposals for the next round of funded projects.
>
> Royce,
>
> I agree with what you wrote, but I want to add to it.
>
> I would like there to be a focus on making FreeBSD more "devops-friendly"
> so that the current generation of devops engineers can pick it up
> and easily deploy it in large cluster and cloud environments.  We need
> to move beyond the 1990's era view of Unix administration where we only
> have a few Unix servers administered by hand by a few sysadmins.
>
> Today's datacenter has hundreds or thousands of nodes.  These nodes
> need to be installed, maintained, and upgraded.  These nodes are more and
> more
> maintained by devops teams who use automation frameworks (Puppet, Chef,
> Ansible,
> Saltstack, CFEngine, etc.) to accomplish these tasks.  devops teams will
> write C and shell script
> if they have to, but are very pragmatic about using newer scripting
> languages like Python, Ruby, etc.
> if it is necessary to get the job done.
>
> What is FreeBSD doing to be more devops friendly?
> How can we make FreeBSD friendlier to people who are trying to deploy
> hundreds and thousands of
> FreeBSD nodes, especially in datacenter and cloud environments?
>
> I would like to see the project and Foundation focus on these types of
> problems.
>
> --
> Craig
> ___
> freebsd-advocacy@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy
> To unsubscribe, send any mail to "freebsd-advocacy-unsubscr...@freebsd.org
> "
>



-- 
Hunter Satterwhite
Systems Engineer, Technical Operations (TechOps)
___
freebsd-advocacy@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy
To unsubscribe, send any mail to "freebsd-advocacy-unsubscr...@freebsd.org"


Re: projects to better support FreeBSD sysadmins

2015-01-13 Thread Craig Rodrigues
On Tue, Jan 13, 2015 at 02:14:24PM -0900, Royce Williams wrote:
> But the overall project list needed to be rebalanced towards system
> administration.  I request that the Foundation consider this when
> calling for proposals for the next round of funded projects.

Royce,

I agree with what you wrote, but I want to add to it.

I would like there to be a focus on making FreeBSD more "devops-friendly"
so that the current generation of devops engineers can pick it up
and easily deploy it in large cluster and cloud environments.  We need
to move beyond the 1990's era view of Unix administration where we only
have a few Unix servers administered by hand by a few sysadmins.

Today's datacenter has hundreds or thousands of nodes.  These nodes
need to be installed, maintained, and upgraded.  These nodes are more and
more
maintained by devops teams who use automation frameworks (Puppet, Chef,
Ansible,
Saltstack, CFEngine, etc.) to accomplish these tasks.  devops teams will
write C and shell script
if they have to, but are very pragmatic about using newer scripting
languages like Python, Ruby, etc.
if it is necessary to get the job done.

What is FreeBSD doing to be more devops friendly?
How can we make FreeBSD friendlier to people who are trying to deploy
hundreds and thousands of
FreeBSD nodes, especially in datacenter and cloud environments?

I would like to see the project and Foundation focus on these types of
problems.

--
Craig
___
freebsd-advocacy@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy
To unsubscribe, send any mail to "freebsd-advocacy-unsubscr...@freebsd.org"


Re: projects to better support FreeBSD sysadmins

2015-01-13 Thread Joshua Smith


> On Jan 13, 2015, at 6:14 PM, Royce Williams  wrote:
> 
> At Craig Rodrigues' request, I'm starting a new thread here branched
> from a freebsd-ports@ thread.  For those who want more context, the
> original thread starts here:
> 
> https://lists.freebsd.org/pipermail/freebsd-ports/2015-January/097462.html
> 
> It was initially about BIND REPLACE_BASE, but branched off into
> general sysadmin concerns that Craig wanted to respond to.
> 
> Royce
> 
> -- Forwarded message --
> From: Royce Williams 
> Date: Mon, Jan 12, 2015 at 7:10 AM
> Subject: Re: BIND REPLACE_BASE option
> To: ports 
> Cc: Deb Goodkin 
> 
> On Mon, Jan 12, 2015 at 4:08 AM, Kurt Jaeger  wrote:
> 
>>> No disputing that, just thinking, is FreeBSD being driven by user need,
>>> financial contributer need, developer need, security need, making things
>>> 'better' or just by people wanting to make their mark in a warped sense
>>> of "it'll all get better"...?
>> 
>> Probably by developer *capacity* (not need) and fire-fighting,
>> like most IT stuff 8-(
> 
> But like most IT stuff, resources are being asymmetrically applied to
> the root causes of the fires.
> 
> Read the list of projects from last quarter:
> 
> - Address Space Layout Randomization (ASLR)

I would hardly consider this esoteric. 

> - amd64 Xen Paravirtualization
> - bhyve

The ability for FreeBSD to host VMs is definitely something that I find very 
interesting and useful. I am a sysadmin. 

> - Chelsio iSCSI Offload Support
> - Debian GNU/kFreeBSD
> - FreeBSD Preseed Installation (PXE)

This also fits right in the making a sysadmin a life easier wheel house. 

> - Jenkins Continuous Integration for FreeBSD
> - New Automounter

An auto mounter that behaves more like what is in other unixes also improves my 
life as a sysadmin. 

> - QEMU bsd-user-Enabled Ports Building
> - VMWare VAAI and Microsoft ODX Acceleration in CTL

Not really sysadmin focused but definitely not esoteric. 

> - ZFSguru
> - Intel GPU Driver Update
> - SDIO Driver
> - UEFI Boot

Like it or not UEFI is the future supporting it well is not optional. 

> - Updated vt(4) System Console
> - Updating OpenCrypto
> - FreeBSD on Newer ARM Boards

> - FreeBSD/arm64
> - LLDB Debugger Port
> - LLVM Address Sanitizer (Asan)
> - SSE Variants of libc Routines for amd64
> - FreeBSD Python Ports
> - GNOME/FreeBSD
> - KDE on FreeBSD
> - The Graphics Stack on FreeBSD
> - Xfce
> 
> The Foundation section also lists these items not overlapping with the above:
> 
> - FreeBSD Journal
> - PostgreSQL performance improvements
> - Ongoing release process
> - Development snapshots

A better release process will likely benefit me as a sysadmin. 

> - VM images for releases

Being able to boot the base system on the hyper visor of my choice with out 
having to muddle through the installer is a huge time saver and a bandit of 
sysadmin a everywhere. 

> - Secure Boot planning
> - Infrastructure hardware
> - Java licensing
> - Summits and summit sponsorship
> - Travel grants, tutorials, and talks
> - New Design and Implementation book
> - Recruitment flyers
> 
> Are there long-term improvement projects that aren't being listed?  If
> so, they should be.

These are just projects sponsored by the foundation. I'm sure there are many 
other developments occurring throughout the project that are not listed here 
because they are not sponsored by the foundation. 

> 
> At face value, the main project list is heavily weighted towards
> relatively esoteric OS features.

See my other comments above. Frankly this is a bullshit statement. 


> The Foundation list is heavily
> weighted towards advocacy and communication (as it should be).
> 
> What is missing are high-level projects to help sysadmins maintain and
> use FreeBSD on an ongoing basis.
> 
> Here are some projects that would help to close the sysadmin gap:
> 
> - Automatic error reporting and analysis

A crash reporting mechanism already exists. 

> - OS and port debugging tools for sysadmins
> - Independent project-wide usability analysis

What does this mean? If you run into a usability or any other sort of problem. 
Submit a PR. 

> - Ports dependency isolation and reduction framework

Doesn't seem like a sysadmin type thing to me. 

> - Ports system reliability parity with Linuxes

Can you provide more details and expand upon this?

> - Searchable, taggable project FAQ

Any number of the projects above are far more beneficial to sysadmin a 
everywhere than this. 

> - Searchable hardware support matrix integrated with bug tracker

+1 for this. 

> - Wiki curation and platform improvements
> 
> These projects decentralize and improve support for sysadmins and new
> adopters.  As a business case for the Foundation, these projects
> should also deeply free up developer resources to focus on other major
> projects.
> 
> In the past, when I have pointed out this "sysadmin gap", I receive
> one of two answers:
> 
> 1. Sounds great. Let us know when you have it finished.


Re: projects to better support FreeBSD sysadmins

2015-01-13 Thread Craig Rodrigues
On Tue, Jan 13, 2015 at 02:14:24PM -0900, Royce Williams wrote:
> At face value, the main project list is heavily weighted towards
> relatively esoteric OS features. The Foundation list is heavily
> weighted towards advocacy and communication (as it should be).

Royce,

Thank you for your post and your analysis.  I agree with everything
you wrote.  My observation is that the FreeBSD developer community
is heavily skewed towards kernel developers and systems developers.
That's why the project list which you mentioned in the
FreeBSD status report has a lot of items for kernel and OS features.

However, FreeBSD has always been more than just a kernel.  The project
sells itself as a provider of a fully usable and integrated operating system.
The kernel is only one component of a fully usable system.

For a while, I worked for Jordan Hubbard at iXsystems, and
when I talked with him, the sense I got is that in the early
days of the project, the focus was much more on having a fully usable
and integrated operating system than it is today.  The early project
founders were much more pragmatic about getting things done and having a usable
system.  They chose the BSD license for practicality, but were not afraid
to use GNU things if there was no equivalently functional BSD licensed tool.
The project was not just focused on
adding esoteric OS and kernel features.  For example, things
like sysinstall, which tried to have a fully integrated menu
for configuring the system, was a big deal in the early 1990's
compared to the competition.  Today, the state of the art has
advanced, and sysinstall looks quite primitive, but the ideas for what
it was trying to accomplish are valid.  However, it was an attempt
at improving usability.

Unfortunately, in recent years, when Kris Moore tried
to integrate newer installer work that he wrote,
he was constantly pushed away because
his code depends on 3rd party libraries such as Qt, which are not
in the base system.  Kris's work is very nice.  I've used his installer
in PC-BSD both in desktop and server modes.
It's a shame that Kris did all this work and was basically told to get lost.
The end result is that Kris had to go and form a separate PC-BSD project 
instead of being
able to improve FreeBSD itself.  The bsdinstall installer that
we have today in the base system does work, but it actually *lacks* features
in comparision to sysinstall which is a 1990's era tool!!

Unfortunately, I think the project has lots its way and gone away from its roots
in the areas of having a usable operating system and has veered towards
esoteric OS and system features.   I agree with you that refocusing Foundation 
efforts
more towards improving usability would be a very good thing.

-- 
Craig Rodrigues
rodr...@freebsd.org
___
freebsd-advocacy@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy
To unsubscribe, send any mail to "freebsd-advocacy-unsubscr...@freebsd.org"