Cockpit motd support
by Allison Karlitskaya
hi,
Cockpit 169 (released today) contains a change to take advantage of the
recently added PAM support for /etc/motd.d to display a helpful note to the
admin about how to start or access cockpit.
The required PAM changes have already landed in Fedora 28.
It seems that the PAM configuration of Fedora 28 (at least in our test
images here) doesn't use pam_motd at all, though.
I'd like to start a discussion about what would be appropriate here. We
want at least a message displayed when people log in to an interactive
session with ssh, but it might also be useful to display a message at the
virtual console, before or after login.
Thoughts?
Thanks in advance,
Allison
4 years, 8 months
Re: Release criteria proposal: installing / removing software
by Adam Williamson
On Wed, 2018-07-18 at 08:49 +0200, drago01 wrote:
> On Wednesday, July 18, 2018, Chris Murphy <lists(a)colorremedies.com> wrote:
>
> > On Tue, Jul 17, 2018 at 3:53 PM, Adam Williamson
> > <adamwill(a)fedoraproject.org> wrote:
> > > On Tue, 2018-07-17 at 14:48 -0700, Adam Williamson wrote:
> > > > I instinctively like the non-split form here because, to me, it
> > > > emphasizes more clearly that "appropriately" applies to all three
> > > > actions.
> > >
> > > To be clearer here, consider these options:
> > >
> > > "...to appropriately install, remove and update..."
> > > "...to install, remove and update appropriately..."
> > > "...appropriately to install, remove and update..."
> > >
> > > To me, it's at least possible that someone might read the first as if
> > > the "appropriately" applies only to the action "install", and the
> > > second as if the "appropriately" applies only to the action "update".
> > > The third, however, can't really be understood in any way *other* than
> > > with "appropriately" applying to all three actions.
> >
> > Use a colon.
> >
> > to appropriately: install, remove, and update...
> >
> > Unambiguous.
> >
>
> Just drop "appropriately" and replace it with a footnote. Then there is no
> need for all of this discussion and the text is easier to read (also
> installing the correct update falls into common sense hence for most people
> it will be clear even without reading the footnote).
There already is a footnote; to me the footnote reads better if it has
a word in the text to key off.
To be honest I don't think anyone's actually pointed out any real
*problem* with the revised draft yet and I'm inclined to just go with
it, after a few more days for substantive feedback.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5 years, 2 months
Re: Release criteria proposal: installing / removing software
by Adam Williamson
On Tue, 2018-07-17 at 15:09 -0600, Nathanael D. Noblet wrote:
> On Mon, 2018-07-16 at 17:32 -0700, Adam Williamson wrote:
> >
> > Basic:
> >
> > "The installed system must be able appropriately to install, remove,
> > and update software with the default console tool for the relevant
> > software type (e.g. default console package manager). This includes
> > downloading of packages to be installed/updated."
> >
>
> Just a small typo/grammar correction I think.
>
> "The installed system must be able to appropriately install, remove,
> and update.."
>
> just moved the 'to' infront of appropriately.. Apologies if that's a
> dumb thing to nit-pick. Otherwise looks good to me.
This is the old English grammatical chestnut known as the "split
infinitive" (or rather, in the case of my draft, the infinitive is
intentionally *not* split).
Both forms are used, and mean the same. The one I chose is sometimes
considered the more 'classically' correct, and some stick-in-the-muds
consider your form to be incorrect. Wikipedia has quite a good article
on it:
https://en.wikipedia.org/wiki/Split_infinitive
I instinctively like the non-split form here because, to me, it
emphasizes more clearly that "appropriately" applies to all three
actions.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5 years, 2 months
Criteria drafts with Server Role references removed
by Adam Williamson
Hi, folks. Here are some quick drafts of the criteria pages with all
requirements rephrased to avoid use of the server role mechanism, which
sgallagh says is to be removed from F29 soon:
https://fedoraproject.org/wiki/User:Adamwill/Draft_Basic_Release_Criteria...
https://fedoraproject.org/wiki/User:Adamwill/Draft_Beta_Criteria_role_rem...
https://fedoraproject.org/wiki/User:Adamwill/Draft_Final_Criteria_role_re...
here are diffs from the current content of pages, for ease of review:
https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_Basic_Rel...
https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_Beta_Crit...
https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_Final_Cri...
Basically I just sort of welded the meat of the requirements from the
nice structure of pages we had set up straight into the criteria pages
:/ It's not great, but it should do the job.
Comments, suggestions etc. welcome.
Obviously we would also want to tweak the PRD and tech spec pages, and
all the role-specific pages themselves, to note that the 'role' concept
is basically dead. I would do that when pushing these changes out, if
they're acceptable to everyone.
Longer term we're kicking around different ideas for what Server might
become in future, but for F29 at least we want to maintain the same
basic functional requirements, minus rolekit itself (we still want to
require freeipa and postgres server functionality to work).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5 years, 2 months
Server SIG Weekly Meeting Minutes (2018-07-17)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
================================================================
#fedora-meeting-1: Fedora Server SIG Weekly Meeting (2018-07-17)
================================================================
Meeting started by sgallagh at 20:01:17 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-1/2018-07-17/serversig...
.
Meeting summary
- ---------------
* Roll Call (sgallagh, 20:01:17)
* What is the meaning of life? (For Server Edition) (sgallagh,
20:05:23)
* ACTION: sgallagh to talk with Fedora Council and Red Hat management
about requests for Server WG (sgallagh, 20:55:36)
Meeting ended at 21:02:05 UTC.
Action Items
- ------------
* sgallagh to talk with Fedora Council and Red Hat management about
requests for Server WG
Action Items, by person
- -----------------------
* sgallagh
* sgallagh to talk with Fedora Council and Red Hat management about
requests for Server WG
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* sgallagh (84)
* adamw (27)
* nirik (21)
* tachoknight (16)
* zodbot (13)
* misc (13)
* mjwolf (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v2.2.2
Comment: https://www.mailvelope.com
wkYEAREIABAFAltOWWIJEHolVWI2uqOjAADm7gCgleRDTbLuEpr4zgn32z76
++NX1O0Anjg1mFHaLWR7+U8jDYUREtBEp7NK
=TdWc
-----END PGP SIGNATURE-----
5 years, 2 months
Release criteria proposal: installing / removing software
by Adam Williamson
Hi, folks!
It's been noted a few times before that we have a release criterion
that requires *updating* packages (or, these days, 'software', to cover
things like modules) to work...but we don't have criteria covering
other basic software management tasks, notably installing and removing.
There is a possible justification for this: so long as update works,
bugs in installation and removal can be fixed with updates. But really,
it seems reasonable to me that we should require basic
installation/removal of packages (and modules, and anything else we may
choose to consider release critical now or in future, e.g. flatpaks,
Shell extensions...) to work on release.
So, I'm proposing we modify the existing Basic and Beta criteria that
cover only updates, to also cover installation and removal. I like this
a bit more than adding separate criteria as the footnotes would be very
similar, and combining allows the footnotes to be shared.
So, the Basic criterion would change from:
"The installed system must be able to download and install appropriate
updates with the default console tool for the relevant update type
(e.g. default console package manager)."
to:
"The installed system must be able to install, remove, and install
appropriate updates for software with the default console tool for the
relevant software type (e.g. default console package manager). This
includes downloading of packages to be installed/updated."
the Beta criterion would similarly change from:
"The installed system must be able to download and install appropriate
updates with the default tool for the relevant update type in all
release-blocking desktops (e.g. default graphical package manager)."
to:
"The installed system must be able to install, remove, and install
appropriate updates for software with the default tool for the relevant
update type in all release-blocking desktops (e.g. default graphical
package manager). This includes downloading of packages to be
installed/updated."
the footnotes would be tweaked to refer more generically to 'software'
and stuff instead of 'updates', just kinda logical changes to reflect
the broadened criterion; I can go into detail on that if anyone wants.
Obviously if the criterion change is agreed upon, we will add test
cases to the test matrices.
Thoughts, comments, suggestions, acks and nacks? Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5 years, 2 months
Server SIG Weekly Meeting Agenda (2018-07-17)
by Stephen Gallagher
We should continue our brainstorming session on the future and purpose of
Fedora Server Edition at our meeting today at 1600 EDT/2000 UTC in
#fedora-meeting-1
5 years, 2 months
Cockpit 172 released
by Martin Pitt
http://cockpit-project.org/blog/cockpit-172.html
Cockpit is the modern Linux admin interface. We release regularly. Here
are the release notes from version 172.
System: Offer installation of PCP
---------------------------------
The System page now shows an "Enable persistent metrics…" link if the [PCP
package is not installed. This is similar to the on-demand installation of the
NFS client packages in Cockpit 169.
Screenshot: https://cockpit-project.org/images/pcp-install-on-demand.png
Software Updates: Improve layout in mobile mode
-----------------------------------------------
The Software Updates page improves spacing and layout in small browser windows
and mobile browsers.
Screenshot: https://cockpit-project.org/images/packagekit-mobile-optimization.png
Remove ability to drop privileges from navigation bar
-----------------------------------------------------
Before this release, Cockpit showed a “Locked” or “Unlocked” status in the
navigation bar. It reflected the “Reuse my password for privileged tasks”
checkbox on the login page. Clicking on “Unlocked” would lock the interface and
drop administrator capabilities.
In general, the capability downgrade feature is not well supported across
Cockpit. Most pages do not respond well to privilege changes.
A non-clickable administrative privilege badge (“Privileged”) replaces the old
interactive locked/unlocked status.
The ability to start cockpit without escalating privileges remains on the login
screen. Dropping privileges at runtime is still available in the user menu,
under "Authentication".
Screenshot: https://cockpit-project.org/images/cockpit-drop-privileges.png
Introduce flow control for all channels
---------------------------------------
The Cockpit API now has flow control to reduce buffering, improve memory usage,
and make the user interface more responsive.
Third-party Cockpit extensions may use the API to transfer large amounts of
data.
A notable example: Welder (https://github.com/weldr/welder-web) downloads
customized operating system from remote machines. Without flow control, Welder
would become unresponsive and use large amounts of memory.
Python 3 support
----------------
Cockpit, along with all unit tests and most integration tests, now supports
Python 3. Building with Python 2 still works, but it is now deprecated.
Get it
------
You can get Cockpit here:
http://cockpit-project.org/running.html
Cockpit 172 is available in Fedora 28:
https://bodhi.fedoraproject.org/updates/cockpit-172-1.fc28
Or download the tarball here:
https://github.com/cockpit-project/cockpit/releases/tag/172
Take care,
Martin Pitt
5 years, 2 months
