F20 System Wide Change: No Default Sendmail
by Jaroslav Reznik
= Proposed System Wide Change: No Default Sendmail =
https://fedoraproject.org/wiki/Changes/NoDefaultSendmail
Change owner(s): Lennart Poettering <lennart at poettering net>, Matthew
Miller <mattdm at fedoraproject org>
No longer install an MTA by default. (Specifically let's remove sendmail from
@core and @standard comps groups.)
== Detailed description ==
Let's change the default install to no longer install an MTA by default.
Specifically, let's remove sendmail from the @standard and @core group.
On today's Internet most SMTP hosts do not accept mail from a server which is
not configured as a mail exchange for a real domain, hence the default
configuration of sendmail is seldom useful. Even if the server is not tied to a
real mail domain, it can be configured to authenticate as a user on the target
server, but again, this requires explicit configuration on both ends and is
fairly awkward. Something that doesn't work without manual configuration should
not be in the default install.
Most MUAs we ship (especially those we install by default) do not deliver to a
local MTA anyway but rather include an SMTP client. Usually, they will not
pick up mail delivered to local users. This means that unless the user knows
about local mail and takes steps to receive local mail addressed to root, such
messages are likely to be ignored.
On top of that, sendmail has always been a quite surprising choice for an MTA,
as most administrators tend to prefer mail systems such as Postfix or Exim
these days, and Sendmail appears to be quite arcane to most.
Administrators should install the MTA of their choice after installation (or
via kickstart) and sendmail should not be the default anymore.
Many other distributions do not install an MTA by default anymore, and so
should we. Running systems without MTA is already widely tested.
The various tools (such as cron) which previously required a local MTA for
operation have been updated already to deliver their job output to syslog
rather than sendmail, which is a good default.
Also see the previous attempt:
https://fedoraproject.org/wiki/Features/NoDefaultMTA
== Scope ==
Simply remove "sendmail" from all default install groups in "comps".
Packages which strictly require a MTA to run might need updating to gain
dependencies on "server(smtp)" (but they needed that before too, so this is
mostly just bugfixing that's useful anyway). If any of the packages in the
default install is one of those, we need to look at it in detail, and find a
solution. However, currently no package of the default install is requiring an
MTA.
Proposal owners: Commit a change to "comps" to remove "sendmail" from it.
Other developers: logwatch/logcheck might need updating to not require an MTA
for delivering log changes. Some packages might need a dependency on
"server(smtp)" added.
Release engineering: nothing really.
Policies and guidelines: nothing really. Maybe the guidelines should clarify
that /usr/bin/sendmail doesn't exist on many systems, but that was already the
case before -- so little changes.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10 years, 10 months
[Test-Announce] FreeIPA AD Trust improvement Test Day tomorrow, 2013-07-25
by Adam Williamson
Hello,
The FreeIPA team is happy to welcome you to a Fedora Test Day that is
being held on Thursday, July 25th.
We would like to invite you to take part in testing of the upcoming FreeIPA 3.3
release containing 2 major improvements for easier deployment of FreeIPA Active
Directory Trust feature to existing environments:
1) Use POSIX attributes defined in Active Directory [1]
With previous FreeIPA releases, users coming from Active Directory to FreeIPA
managed machines were always assigned POSIX attributes (UID and GID) by
algorithmic mapping.
However, in some deployments, Active Directory users and groups already have
defined custom POSIX attribute values (UID and GID), which may then be
leveraged on Linux machines via other 3rd party Active Directory integration
solutions. Administrator may choose to keep the values to not disrupt file
ownerships.
With FreeIPA 3.3, FreeIPA Active Directory Trust may be configured to use these
attributes when Active Directory user authenticates to Linux machines.
2) Expose POSIX data on legacy systems without recent SSSD
Administrators may have a deployment of machines which cannot use the recent
SSSD with Active Directory Trust support but would still like to be able to
authenticate with Active Directory user to these machines. This may affect for
example older Linux machines, UNIX machines.
With FreeIPA 3.3, Administrator may configure a compatibility LDAP tree which
will contain identities of the Active Directory users to the legacy systems.
These systems may then leverage standard LDAP authentication in this tree
allowing selected Active Directory users to authenticate.
To read more about the Test Day and suggested tests, see the following link:
https://fedoraproject.org/wiki/Test_Day:2013-07-25_AD_trusts_with_POSIX_a...
Thank you for your help and participation!
The FreeIPA team
[1] http://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD
[2] http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
_______________________________________________
test-announce mailing list
test-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
10 years, 10 months
Self Introduction
by Georgi Valkov
Dear Community,
My name is Georgi Valkov and I'm a 26 year old FOSS user and enthusiast
situated in Bulgaria. My last job was at Cisco, where I did build/release
engineering and internal automation tools. After a year long break from work,
I've decided to go back to school and earn myself a Master's Degree in
Distributed Systems and Networks.
My first package review request is for python-evdev [1], a Python binding to
the Linux input subsystem (evdev and uinput):
https://bugzilla.redhat.com/show_bug.cgi?id=879740 (second comment)
Fedora is an amazing project and is of great use to me - I can only hope I'll
be able to be of some use to it as well.
Regards,
Georgi
[1]: https://github.com/gvalkov/python-evdev
10 years, 10 months
Fedora ARM Weekly Status Meeting Minutes 2013-07-24
by Paul Whalen
Thanks to those that were able to join us for the status meeting today, for those unable the minutes are posted below:
Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-07-24/fedora-meeti...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-07-24/fedora-meeti...
Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-07-24/fedora-meeti...
===================================================
#fedora-meeting-1: Fedora ARM weekly status meeting
===================================================
Meeting summary
---------------
* 0) Status of ACTION items from our previous meeting (pwhalen,
20:02:11)
* LINK:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-07-17/fedora-meeti...
(pwhalen, 20:02:12)
* ACTION: dgilmore to setup koji hub&db for aarch64 (pwhalen,
20:03:57)
* ACTION: handsome_pirate Is talking to ghc upstream (pwhalen,
20:04:45)
* ACTION: msalter is working on openjdk for aarch64 (pwhalen,
20:05:50)
* complete, built! (pwhalen, 20:06:03)
* ACTION: kylem to create a list of new supported platforms in 3.11
(pwhalen, 20:06:15)
* 1) Problem packages (pwhalen, 20:09:46)
* java (being worked on) (pwhalen, 20:11:10)
* LINK: java: https://bugzilla.redhat.com/show_bug.cgi?id=985811
(bconoboy, 20:11:15)
* python3 https://bugzilla.redhat.com/show_bug.cgi?id=986713
(pbrobinson, 20:11:56)
* redhat-lsb has issues, but is being worked on by its maintainer
(bconoboy, 20:13:18)
* LINK: glibc is being built with neon, breaking tegra2/olpc:
https://bugzilla.redhat.com/show_bug.cgi?id=985342 (bconoboy,
20:14:43)
* 2) Kernel Status Update (pwhalen, 20:20:40)
* In 3.11 there is considerable breakage. Tegra is being worked on
now. Next is OMAP4. (bconoboy, 20:23:07)
* 3a) Aarch64 Status Update, problem packages (pwhalen, 20:27:02)
* 11420/13606 packages built, 4832 of them containing aarch64
components. The build queue is currently empty. (bconoboy,
20:29:01)
* about 2000 packages remain. These will require requeueing or build
fixes. (bconoboy, 20:29:21)
* Stage 3 is retired - remove it from /etc/mock/stage4-aarch64.cfg or
mock will fail (bconoboy, 20:29:44)
* Stage 3 is retired - remove /etc/yum.repos.d/stage3 or yum will
produce errors (bconoboy, 20:30:18)
* ACTION: bconoboy to start building f19-updates in stage4 (bconoboy,
20:37:50)
* 4) Open Floor (pwhalen, 20:42:25)
* Utilite support being investigated- check back in 4 weeks
(bconoboy, 20:45:13)
* mesa built with llvm 3.1 results in gnome-shell working (bconoboy,
20:45:32)
* ACTION: kylem now debugging llvm 3.3 mcjit, will then trace
gnome-session (bconoboy, 20:47:10)
Meeting ended at 20:50:36 UTC.
Action Items
------------
* bconoboy to start building f19-updates in stage4
* kylem now debugging llvm 3.3 mcjit, will then trace gnome-session
Action Items, by person
-----------------------
* bconoboy
* bconoboy to start building f19-updates in stage4
* kylem
* kylem now debugging llvm 3.3 mcjit, will then trace gnome-session
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* bconoboy (61)
* pbrobinson (55)
* pwhalen (26)
* kylem (21)
* dgilmore (13)
* handsome_pirate (11)
* zodbot (9)
* ahs3 (5)
* ddd_ (5)
* masta (2)
* msalter (2)
* dmarlin (1)
* oatley_ (1)
* agreene_ (1)
* jcapik1 (1)
* jcapik (0)
* ctyler (0)
* agreene (0)
* jonmasters (0)
10 years, 10 months
Self Introduction
by Marcus Asshauer
Hello,
my name is Marcus and I am 32 years old, working as senior system engineer
and life in Germany. My focus is on monitoring and automation in data
center enviroments. I am using linux since 2000 and have tried nearly all
main distributions.
I choose fedora because of the integration of new technologies and the good
integration of the community into redhat.
Doing packaging is interesting for me, to learn building software packages
to reuse it without any further work and distribute software to a large
amount of server.
Best regards
Marcus
10 years, 10 months
Fedora ARM Weekly Status Meeting 2013-07-24
by Paul Whalen
Good day all,
Please join us today (Wednesday, July 24th) at 4PM EDT (8PM UTC)
for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode.
On the agenda so far..
0) Status of ACTION items from our previous meeting
1) Problem packages
2) Kernel Status Update
3) Aarch64 - Status Update, problem packages
- Koji Update
4) Open Floor
If there is something that you would like to discuss that isn't mentioned
please feel free to bring it up at the end of the meeting or send an email
to the list.
10 years, 10 months
Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)
by Peter MacKinnon
Shout out to my fellow Flocker, Matt...
-------- Original Message --------
> Subject: RFC: Proposal for a more agile "Fedora.next" (draft of my
> Flock talk)
> Date: Mon, 22 Jul 2013 09:38:54 -0400
> From: Matthew Miller <mattdm(a)fedoraproject.org>
> Reply-To: Development discussions related to Fedora
> <devel(a)lists.fedoraproject.org>
> To: Fedora Development List <devel(a)lists.fedoraproject.org>
>
> <snip>
>
> Obviously, no-bundled-libs is a crucial part of the packaging guidelines
> today. As a sysadmin, I know why it's important. This is not just a noble
> goal, but also something that pragmatically makes systems better. But,
> it's
> also keeping us from having software that people really use in Fedora.
> Chef
> and Hadoop are two big examples. This hurts us more than it helps the
> world.
> So, in some areas, we need a different approach.
>
The Big Data SIG is trying to adapt Hadoop 2.x into Fedora for F20
<https://fedoraproject.org/wiki/Changes/Hadoop>, and I'll be sharing our
insights on this at Flock <http://sched.co/185PNI9> in a couple of
weeks. In Matt's conceptual architecture I suppose Hadoop Common would
live in the Ring 2-to-3 orbit somewhere. It is a core in it's own right
(it provides a distributed, replicated file system) in that there is an
every growing software ecosystem that has emerged around it, and the SIG
would like Fedora to be the OS of choice for that ecosystem. Stable
enough for deployment but a feature-rich, current and productive
environment for the developers in that evolving ecosystem. The Hadoop
runtime is an orchestration of JVM-based daemons which can be viewed as
system-level services, thus an obvious candidate for well-defined
integration with Fedora via packaging: correct permissions, systemd
scripts, logs, etc.
However, the root of that core is a set of older and deprecated Java
dependencies (e.g., Jetty 6, Tomcat 5.5) which are expressed via the
Apache Maven build tool. The "quick and dirty" label used by another
poster of a VERY popular build tool like Maven does it a disservice. The
fact is that it is exceedingly popular in the Java development community
and has been for some time. Anyway, the challenge for this project is
the reconciliation of it's stable dependencies versus the ever-changing
bleeding edge that is typically found in the latest Fedora release. A
lot of our efforts so far have been the various API and build
specification changes necessary to try to make Hadoop fit into Fedora.
So far, so good...sort of. We can make the basic use case and tests work
with the modified dependencies but in doing so we risk giving up parity
with the Apache baseline (including the JRE) and potentially lose out to
other so-called "dirty RPMs". Ideally, we wouldn't be forced into some
of these adaptations and compromises if there were Fedora packaging
alternatives that would give us (a SIG ring?) more control over the
bundles needed by Hadoop as opposed to the ones mandated by the latest
Fedora release. Make no mistake: patches are fed from the SIG to the
Hadoop community to try to bump the versions there. But the upstream
project can't and won't chase an ever-vanishing point in the distance.
They view their lower dependencies much like a stable OS such as RHEL
and change should be deliberated there.
I feel like Matt has at least kick-started the discussion around how
Fedora could evolve to support orthogonal dependency models that more
readily adapt to external projects like Hadoop. Not that our SIG has any
profound answers. :-)
Thus, we are very interested in _any_ packaging architecture proposals
that could help relieve our initiative's pain points, and look forward
to further constructive discussion of the same.
My $0.02,
\Pete
--
Peter MacKinnon
MRG Grid/Big Data
Red Hat Inc.
Raleigh, NC
10 years, 10 months
