Fedora, UUIDs, and user tracking
"User tracking" is generally contentious in free-software communities—even if the "tracking" is not really intended to do so. It is often distributions that have the most interest in counting their users, but Linux users tend to be more privacy conscious than users of more mainstream desktop operating systems. The Fedora project recently discussed how to count its users and ways to preserve their privacy while doing so.
Ben Cotton brought
up the topic in the context of a proposal for
Fedora 30. Instead of the current method of counting unique IP
addresses that request
updates from the DNF mirrors, which is an unreliable estimator of Fedora
usage, the proposal would create a unique user ID (UUID) for each installed
system that would be sent with DNF mirror-list requests. It
explicitly calls
out privacy concerns: "We don't want to track; just count.
"
The proposal outlines the kind of information that the project would like
to count, including the version of Fedora, the
Fedora variant (or spin), and the architecture of the machine. It would
also be useful to have some
way to distinguish long-lived installations from one-off test systems in
virtual machines.
Currently, variants cannot be distinguished and the unique IP counting
method both undercounts systems behind network address translation (NAT)
and overcounts systems that change IP addresses frequently. The UUID is
similar to what openSUSE uses, so "this is ground already
traveled
".
Using the machine ID (stored in /etc/machine-id) as the UUID is not part of the plan, since it may be used in other ways that would facilitate tracking. So some kind of random UUID would be generated for this purpose. But, as Lennart Poettering pointed out, sending a UUID makes tracking possible even if the project doesn't want to do that tracking. Essentially, users would need to trust that the project isn't doing the tracking because it says it isn't. While he was skeptical that Fedora really wanted to use a UUID that way, he did suggest using an application-specific machine ID, like those calculated by sd_id128_get_machine_app_specific(). That way, Fedora would be using an existing mechanism that generates a UUID using the machine ID and an ID specific to the counting application.
Poettering also mentioned that Ubuntu counts installations via NTP, which
might be an option if Fedora wanted to run its own NTP servers. Both
Ubuntu and Fedora configure their systems to regularly ping the NTP servers.
Another possibility would be to send a "countme" flag once a day as
part of the captive-portal and connectivity detection that is already
installed with Fedora, but that did not sit well
with Kevin Kofler. He called the existing
NetworkManager-config-connectivity-fedora package "spyware
"
and does not install it on his systems.
Fedora
project leader Matthew Miller (who is also the owner of the feature
proposal) said that
the connectivity check could be used but it would only count a subset of
desktops and not other types of installations, such as server, cloud, or
container. In addition, setting up NTP servers would be much more work
than hosting a UUID-counting service, he said.
Miller said that
the intention is to rotate the logs "fairly
frequently
", but that is not really visible to users so there is
still a trust factor present. But Tom Gundersen suggested
another approach:
Then you make sure that all UUIDs submitted by a given machine during a given time window are the same, but UUIDs submitted in different windows are not related, and you don't have to trust the server to respect your privacy.
That approach would "make sense
" Poettering said, though
he still advocated using NTP or the "HTTP ping" that is done as part of
the captive-portal detection. Others, such as Bruno
Wolff III, are worried that even if the UUIDs
are changed frequently, users still have to trust Fedora (or someone who
gained access to the logs) not to correlate UUIDs, IP addresses, and other
information to track users that way. Beyond that, Nicolas Mailhot is concerned
about interaction with the EU General Data Protection Regulation (GDPR); that
requires a shift in thinking about how data can be misused:
Wolff also pointed out that attackers may try to send UUIDs that are unexpected. Those could be generated to try to attack the system in some way or they could simply be strings containing profanity or other "not safe for work" (NSFW) content. He wants to ensure that the actual UUID strings don't end up in reports or require review by humans. Even ensuring that the strings are valid hexadecimal doesn't preclude inventive usage that could embarrass the project or offend people. Beyond that, UUIDs could be changed more frequently to try to inflate the statistics.
As these privacy and other problems with the UUID scheme were being discussed, Poettering came up with a scheme that alleviated most of the problems that were identified. He proposed that a "countme" flag simply be added to a single mirror-list query each week. The sum of all such queries over a week's time should provide an accurate estimate of the number of Fedora systems. That way, UUIDs need not be stored, which removes much of the concern—data that is not stored cannot be misused.
Poettering followed up by noting that avoiding even the appearance of tracking will likely result in fewer users disabling the counting mechanism. Miller was enthusiastic about the idea; he suggested that since there would be no UUID associated with the information, the "countme" flag could increment once per week, which would give some additional information about the longevity of systems—without providing much information that could be used for tracking.
It would not even necessarily require that every machine reported, Roberto Ragusa suggested. Machines could decide whether to report based on some property of their machine ID (e.g. divides evenly by 1000) or by combining machine ID and the date so that the counted systems would change over time. Then the counts could simply be multiplied by whatever is used as a modulus to provide the actual estimate.
Overall, there were few complaints about the simpler counting mechanism. Miller has updated the proposal using Poettering's method; it should be posted to the mailing list soon, once he receives some feedback from the DNF developers. It seems likely that Fedora 30 will have the feature when it is released, which is currently scheduled for the end of April.
We have looked at other user-counting initiatives and proposals along the way. In 2010, there was a proposal to add UUID tracking to Yum, but Fedora has been trying to figure how to unobtrusively count users for longer than that. A 2006 scheme involving a tracking image was proposed for Fedora Core 7. More recently, the Django web-framework project discussed adding analytics that would report to Google servers, which was not popular with Debian (at least).
There is a certain amount of tension between the needs of a distribution or software project and the needs of users—especially when it comes to privacy issues. Being able to show the existence of more project users will generally lead to a higher profile and potentially more funding for development and other activities. Counting variants can also help projects make better decisions about where to allocate their scarce resources. But many users do not want to be tracked, though they may be willing to be counted. This Fedora proposal seems like it finds a reasonable balance by reusing an existing mechanism without adding something that could be tracked. It will be interesting to see what Fedora finds once it rolls out this counting feature to users.
Index entries for this article | |
---|---|
Security | Privacy |
Posted Jan 15, 2019 18:14 UTC (Tue)
by dowdle (subscriber, #659)
[Link] (1 responses)
No matter what you do, it won't be accurate but it'll be MORE accurate than in the past.
Posted Jan 15, 2019 19:01 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
A subset of users are never going to be counted without some intrusive per user registration system which is definitely not worth the cost
> No matter what you do, it won't be accurate but it'll be MORE accurate than in the past.
Indeed
Posted Jan 15, 2019 18:20 UTC (Tue)
by davidstrauss (guest, #85867)
[Link] (2 responses)
The addition of sequence numbers -- combined with the client IP addresses -- could allow identifying systems in a way similar to the approaches that de-mask NAT by relying on IP and TCP fields like sequence numbers. It would be better for clients to only classify themselves into demographic-style buckets: less than an hour, 1h-1d, 1d-1w, 1w-1m, 1m-1y, 1y+.
Posted Jan 16, 2019 13:44 UTC (Wed)
by sgallagh (guest, #80524)
[Link]
Posted Jan 16, 2019 18:42 UTC (Wed)
by mattdm (subscriber, #18)
[Link]
Posted Jan 15, 2019 22:28 UTC (Tue)
by jhoblitt (subscriber, #77733)
[Link] (10 responses)
```
`exclude=NetworkManager-config-connectivity-fedora*` just went into my `dnf.conf`.
Posted Jan 16, 2019 13:33 UTC (Wed)
by sgallagh (guest, #80524)
[Link] (9 responses)
This is exactly the same mechanism used by iOS and Android (and Windows and OSX I think).
This information is not really useful for the information we want to gather, which is basically
* Trends in the number of active users (this is *not* the same as an exact user count)
The best we could possibly get from those logs would be "This number of unique IP addresses accessed this site". That's meaningless when you figure in that most Workstation systems are behind NAT devices (especially those at universities which probably results in a massive under-counting).
Posted Jan 16, 2019 14:06 UTC (Wed)
by ibukanov (subscriber, #3942)
[Link] (1 responses)
Posted Jan 16, 2019 14:37 UTC (Wed)
by excors (subscriber, #95769)
[Link]
Posted Jan 16, 2019 18:58 UTC (Wed)
by jccleaver (guest, #127418)
[Link] (5 responses)
And if anyone cared about privacy, it wouldn't do that by default. Opt-in for this kind of stuff.
You don't even need place any sort of HTTP call as your initial primary detection mechanism; there are other ways to do it, including comparing host records for disparate DNS entries and looking for sudden RFC space responses in a cached value. And final validation could always ask for approval before an HTTP request, and pick something innocuous (example.com) since you're only going to hit it once, not 12x/hour from all connected clients. Or make it GUI-configurable, or import the homepage setting from common browsers, or any number of other options...
Posted Jan 16, 2019 19:11 UTC (Wed)
by sgallagh (guest, #80524)
[Link] (4 responses)
That's a significant overstatement. Many of us in the Fedora Project care very deeply about privacy. Which is why this information isn't kept and stored or used in any way to identify individuals. It is, however, so extremely useful that having it enabled by default is in the best interests of the users of the Fedora Workstation. We document how you can disable it if you're so inclined (read: paranoid). Honestly, the only things we can learn from this is that there exists at least one Fedora Workstation connected to the Internet at that IP address. We cannot (and would not) collate this information with anything else and we don't send any information across this connection. And, frankly, we don't even actually know that it must be Fedora, because it's just a configuration setting available to anyone using Linux. If another distro decided to use our site for this connectivity test, we would have zero way to tell (though if we saw a sudden massive uptick in bandwidth usage, we might have to find a way to address that somehow for purely economic reasons).
Lastly, it's a trivial config setting. Don't want to use our site? Great! Set up your own site. Point /usr/lib/NetworkManager/conf.d/20-connectivity-fedora.conf at any website that returns a 200 HTTP message and you're done.
Posted Jan 16, 2019 23:34 UTC (Wed)
by jbicha (subscriber, #75043)
[Link]
Maybe you can help get the Connectivity Checking switch in to the GNOME Settings > Privacy panel. It's been in Ubuntu for over a year. I think I've done about as much as I can do to push it forward (including updating the patch today). It's being held up by what feels to me like unfair design hurdles.
https://gitlab.gnome.org/GNOME/gnome-control-center/merge...
Posted Jan 28, 2019 2:41 UTC (Mon)
by Garak (guest, #99377)
[Link] (2 responses)
Posted Jan 28, 2019 3:24 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
It is not a slur. I have seen it used as a functional description is many software settings.
Posted Jan 30, 2019 13:22 UTC (Wed)
by codeofdrama (guest, #127444)
[Link]
Perhaps it would be less divisive to call the setting itself "paranoid" instead of the people.
Posted Jan 16, 2019 20:00 UTC (Wed)
by johannbg (guest, #65743)
[Link]
Posted Jan 15, 2019 22:39 UTC (Tue)
by nilsmeyer (guest, #122604)
[Link] (5 responses)
To me it sounds more like collecting data for the sake of collecting data. While the technical solutions sound quite elegant there has to be a better way to solicit quality feedback.
Posted Jan 16, 2019 13:37 UTC (Wed)
by sgallagh (guest, #80524)
[Link] (4 responses)
The purpose of data like this is to identify patterns of usage. For example, if we start getting a more accurate count of the relative number of users that install Fedora Server vs Fedora Workstation, we can understand where we should spend more of our limited resources working on improvements.
Posted Jan 16, 2019 20:18 UTC (Wed)
by johannbg (guest, #65743)
[Link] (1 responses)
Are you saying that Gnome desktop will be scratched if it does not meet some usage critera or for that matter other products,modules could be sacrificed in order to force uptake in other products,modules to justify it's continued existance in the product portfolio at the cost of existing users of said product and the entire Fedoras end users privacy?
Is not the reality that IBM/Red Hat needs to know this information to decide where it wants to spend it's money/workforce contribution in the project. Perhaps the next step will be start selling that information as well you know to keep meeting laid out paychecks and other expences?
Posted Jan 17, 2019 9:53 UTC (Thu)
by nilsmeyer (guest, #122604)
[Link]
This is why there is now only one text editor around.
Posted Jan 17, 2019 10:13 UTC (Thu)
by nilsmeyer (guest, #122604)
[Link]
I think the selection bias could work in your favour, you will only get responses by people who care enough to respond and you get consent as well. The problem that you're getting mostly complaints is that you mostly only solicit complaints - I can file a bug or an issue but I can't really file a commendation when I like something. Look for example how proprietary app stores and apps do it: They have a review system in place and some applications actively solicit feedback ("please rate [blah] the app store"). So just as an example you could put a short message in /etc/issue (I know canonical uses it for advertising) along the lines of "Like Fedora Workstation? Please tell us about it [link]".
I believe it's a matter of asking the right questions and interacting with your users at eye-level.
> The purpose of data like this is to identify patterns of usage. For example, if we start getting a more accurate count of the relative number of users that install Fedora Server vs Fedora Workstation, we can understand where we should spend more of our limited resources working on improvements.
I think that's the wrong approach to take. First and foremost you should work on something that you find rewarding and that helps you, not something that wins out in a popularity contest - by that metric people should volunteer for Microsoft instead of improving Fedora Workstation.
Posted Jan 18, 2019 9:22 UTC (Fri)
by flussence (guest, #85566)
[Link]
The latter option never gets taken by FOSS projects of this size. Fedora has a chance to revolutionize the industry! ;-)
Posted Jan 16, 2019 7:47 UTC (Wed)
by amarao (guest, #87073)
[Link] (17 responses)
Debian have much cleaner approach: there is a `popularity-contest` package to track package use. It has user UUID, but it's a single package and users are free to install/remove it at wish. Moreover, an installer is clearly asking about 'opt-in' for it. 'popcon' stats are definitively in public interest (as it influences the base packages in the base package set for next distro).
I can't understand what is the public interest in the user count.
Posted Jan 16, 2019 13:41 UTC (Wed)
by sgallagh (guest, #80524)
[Link] (16 responses)
We don't specifically care how many users there are, we care if it's growing or declining and *where* it's growing and declining. So the proposals are ways to get a better picture of what the project is doing right and wrong. Are we growing our users faster than we used to with Fedora Workstation? Great! Let's keep that momentum. Alternately, is Fedora Server seeing a sharp decline? We should probably re-evaluate some of our decisions.
Right now, that information doesn't exist in a meaningful way. We have some *very* rough estimates of usage of Fedora as a whole, but virtually no data at all on the various sub-projects within it.
Posted Jan 16, 2019 14:56 UTC (Wed)
by amarao (guest, #87073)
[Link] (1 responses)
In our current society, any tracking information is against user. Any. Why? Because there is always a third party actor nearby, gathering this information. You think it helps you to check distro momentum, but in reality it's an excellent way for the man in the middle to join together two independent connection log entries from different IPv6 addresses. Privacy extension had randomized IPv6, and two Fedora machines had became indistinguishable from a single machine... Until it send count-me-in packet with a specific number which clearly give an answer that those two machines are the same.
Do we really want this?
Posted Jan 16, 2019 16:23 UTC (Wed)
by mattdm (subscriber, #18)
[Link]
But even then, I'm proposing a granularity of one week, with a maximum number of, say, 60 — covering the expected lifecycle of a single Fedora release. That means the number wouldn't provide much by way of useful disambiguation for an attacker.
Posted Jan 16, 2019 22:04 UTC (Wed)
by johannbg (guest, #65743)
[Link] (13 responses)
Thats irrelevant, what matter is if the contribution back to an project or distribution is increasing or declining because thats what keeps the project or distributions afloat
But let's say that an distribution can accuratly gather that statistic, then there is nothing that says it's direction is the direct cause for example for an negative result.
It could be for example that a another distribution is currently serving hotter sauce, the hot dog of the month ( or people just go upstream to download a prebuilt ( docker ) image and they dont care on top of which distro the application or application stack runs on top off ) or participate in downstream distribution efforts or it could also just be the interest in Linux ecosystem is declining right...
How are you going to seperate the enviromental factor from the project direction short answer, it cant be done or atleast not without spending resources that the community cant afford in trying to do so.
mkosi+systemd literally put it in the hands of the end user to build his own custom distribution image or container for whatever purpose they need and run it or download a docker image and run it in systemd.
So now the administrator or user might look for an management and provising tool in the distribution since he has so many docker images to maintain, which begs the question how well available those provisining and management tools all are in Fedora and how well supported.
For example take the red hat product stack ovirt,foreman,ansible, ansible tower all that stuff, is it available in Fedora or only in a copr repo with the usual disclaimer of shoot your self in the head rather then to use said copr repo or is it only available in package repo upstream or as an docker image upstream???
If all the popular upstream images are for example running debian or ubuntu, of course the first thing that pops in the new end users head is to join debian/ubuntu community not Fedora.
Which leaves the existing Fedora/RHEL/CentOS local admin that wants to run the fancy Red Hat product stack but is it available as rpms in Fedora, the answer to that is no so why should they use Fedora?
Documentation nope Arch owns that and has for years,
Fedora Workstation does not come with all media support so thats no go for novice end user who just needs an Gnome distribution with full media support and flatpak ( linux mint propably owns that market.)
Which leaves us witb the upcoming sbc/tinker/pi generation. No armbian owns that now...
The project has been on a downhill spiral ever since Matt took over and the rings nonsense got implemented. His modular approach would never work as I pointed out at that time.
At this point, Fedora needs to go back to it's roots of being genering,clean the core/baseOS as should have been done from the start, provide all the Red Hat product stack ( or it's open upstream equallent ) as rpm in the distribution so the remaining admins dont vanish into the cloud and the distribution put on a serious diet by shaving off roughly 7k components from the distribution so it becomes agile enough again to deal with the changes in the linux environment and then just hope for the best...
JBG
Posted Jan 17, 2019 18:28 UTC (Thu)
by jccleaver (guest, #127418)
[Link] (12 responses)
I really couldn't agree with this more.
"Fedora Workstation/Desktop" can do what it wants -- which seems to be the reference implementation for GNOME and that's it -- but "Fedora", in the context of being the successor to RHL, the owner of rawhide, and the de facto upstream for the entire Red Hat ecosystem, *MUST* change. In trying to be all things to all people, while focusing on Lennart's laptop, it's consistently targeting questionable cadences and questionable technical movements, frustrating the wider Red Hat ecosystem and community, all while naively claiming to be doing something for Linux on the Laptop.
"Fedora Project" as a project should factor out everything that applies to all RPM downstreams and focus on the core, incremental infrastructure necessary to keep that running. Enforce RPM standards that *can* *now* be applied and used by all distributions. Enhance copr, pagure, and so forth to provide resources for the entire RH community.
"Fedora Project" can and should QA and release reference releases for this core functionality, but those are indeed intended to be reference releases, of interest mostly to Linux enthusiasts, distribution developers, and theoreticians, without intent of these *necessarily* being market winners in and of themselves. "Fedora Workstation" can be a market winner. CentOS can be a market winner, a RH clone that doesn't use systemd as PID 1 can be a market winner, a tiny RPM-distro for embedded can be a market winner, but Fedora reference releases shouldn't.
Once steps like this start being taken, the RH community as a whole will start functioning better again.
Posted Jan 17, 2019 22:49 UTC (Thu)
by johannbg (guest, #65743)
[Link] (11 responses)
I would argue quite the opposite as in an distribution ( not just RH ) that is not using systemd cannot be a market winner.
Modern infrastructure,cloud, container vendors and upstreams are heavily using systemd features to deploy,test and run on it.
Posted Jan 17, 2019 23:12 UTC (Thu)
by jccleaver (guest, #127418)
[Link] (10 responses)
There's still a lot of EL6 out there in deployment
Posted Jan 18, 2019 0:32 UTC (Fri)
by johannbg (guest, #65743)
[Link] (9 responses)
Just this evening I did 10 fresh fedora installs ( install + test + delete ) and two debians for the same purpose ( confirm if bug was present there as well ) all in ca half an hour which is something I would never have done if either os or both would still be on legacy sys v init, let alone in half an hour.
Posted Jan 18, 2019 6:47 UTC (Fri)
by jccleaver (guest, #127418)
[Link] (8 responses)
Well, one man's "complication" is another man's API stability requirement, or general shared library conflict (ditto), or if-it's-not-broken-don't-fix-it decision. CentOS and RHEL 4 -> 5 was rough at times (especially if you were trying to use Xen), but EL5->EL6 was incredibly smooth. EL6->EL7, definitely not so much. Many I know who've been staying on EL6 were doing it explicitly and consciously, which didn't seem to be the case for EL5.
> Just this evening I did 10 fresh fedora installs ( install + test + delete ) and two debians for the same purpose ( confirm if bug was present there as well ) all in ca half an hour which is something I would never have done if either os or both would still be on legacy sys v init, let alone in half an hour.
If it's a "fresh fedora install" then you're either composing via new anaconda run, using kickstart, or cloning. I'm assuming by "install" you mean a kickstart, but having just done seven automated EL6 VM builds earlier today I'm hard pressed to think of why that would take so long or why you wouldn't be able to too. Kickstart should take a few minutes at most. Boot takes <1m. Do it in parallel depending on your provisioning system. Automating deployments is not difficult, and nothing about regular init blocks this.
Posted Jan 18, 2019 8:22 UTC (Fri)
by johannbg (guest, #65743)
[Link] (7 responses)
Today if a server,vm misbehave it's just shoot in the head and one or more new instance is born to take it's place. systemd spawned containers only live for as long as they are needed and created with a git commit.
The time it takes to generate an image using official mirrors on this host with the method I used is 1m50.053s or so per host so roughly 15m went on building the images and another 15m in testing.
Would be faster probably if I bothered to run internal mirrors but then I would have to mirror 4 distro's ( Arch,Debian,Fedora,OpenSuse ) and different releases of those distro's but thats not high on my priority list thou that might change if fedora is about to track it's user base...
Posted Jan 18, 2019 9:33 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (5 responses)
I never understood this, wouldn't you want to at least diagnose the problem and fix whatever caused the problem so that the problem goes away for future server/vm/container instances?
Posted Jan 18, 2019 9:56 UTC (Fri)
by amarao (guest, #87073)
[Link] (3 responses)
>I never understood this, wouldn't you want to at least diagnose the problem and fix whatever caused the problem so that the problem goes away for future server/vm/container instances?
As operator I can give you the reason. The key reason is a pride. We CAN shoot any node to the head and keep system running. So everyone talking about 'cattle' not with intention to cause a massive extinction in VM population but as a token of pride.
For the real cases it's mixed. As much as I love to work with Linux, I know how badly it can start to behave in some conditions. One unresponsive block device may brick any server to the level when everything is screwed. Some processes are in TASK_UNINTERRUPTIBLE, and this is the end of the game for the well-behaving system.
Replaced drive got a new letter instead of the old one because old one died with traces - old name is still used.
tmpfs is huge breach in a memory logic, as you have buffers which can not be discarded and all monitoring do not know how to detect 'low memory' condition anymore.
etc, etc. Some of bugs are so 'vendor fault' that it's easier to reboot than to report bugs (example: https://github.com/amarao/lsi-sata-fuckup, bug is now 7 years old, and this script is still hangs IO on whole enclosure).
Sometimes it's a well-known fault in application, but it's easier to cover it with load balancer than to debug it.
To deal with all this, there is the approach when individual server does not need have more reliability then a hard drive. We do 'raids' of buggy servers and this is fine.
If some fault types are often enough it may worth to investigate it. Rare ones are just silently ignored (can't reproduce). If operator have time, s/he can go to server and do some debug, but this is operators time, and there is a bug tech. dept in whole infrastructure to waste it in rare issue of incompatibility of beep with colctr.
Posted Jan 18, 2019 17:51 UTC (Fri)
by jccleaver (guest, #127418)
[Link] (2 responses)
Sure, I used to do this too with redundant HA systems. But once you've physically pulled the power plug on one box once and your service has kept working, you don't need to *keep doing that* to prove that to anyone anymore.
That's supposed to provide operational support for your service, not be part of the design whenever there's the slightest hint of something unusual.
Posted Jan 23, 2019 18:52 UTC (Wed)
by edgewood (subscriber, #1123)
[Link] (1 responses)
Posted Jan 23, 2019 19:38 UTC (Wed)
by jccleaver (guest, #127418)
[Link]
The problem is that that leads to epistemological issues that fly in the face of real-world reasoning. Instead of worshiping at the altar of A/B tests, one can focus on the things that matter operationally. Stateless cattle are a tool, one of many, but they are not the end-all and be-all of operation any more than constant Gentoo-like recompilation for performance improvements "just in case" are.
Process matters, and the Operations side of DevOps have formed a new, artificially restrictive religion around this design methodology.
Posted Jan 18, 2019 10:23 UTC (Fri)
by johannbg (guest, #65743)
[Link]
Pattern needs to have emerged before issue is looked at otherwize you could be waisting time, resources thus money chaising down anomaly, that corner case bug every one love...
Posted Jan 18, 2019 17:47 UTC (Fri)
by jccleaver (guest, #127418)
[Link]
Yes, I quite remember the "old days", but this entire model being pushed is a pendulum too far in the opposite direction. Very, very few entities have the actual need for cattle (c.f. https://xkcd.com/1737/ ) If you're Netflix and you have 500,000 hosts all decrypting H.264 or something and data locality concerns are handled elsewhere, then fine -- good for you. The rest don't have "cattle" like that, but they're not "pets" except for key systems... they're "fleets". And as any auto-mechanic knows, just because everything is the same model doesn't mean the workload has the same effect on a car.
> Today if a server,vm misbehave it's just shoot in the head and one or more new instance is born to take it's place. systemd spawned containers only live for as long as they are needed and created with a git commit.
That's not engineering, that's playing with tech.
> The time it takes to generate an image using official mirrors on this host with the method I used is 1m50.053s or so per host so roughly 15m went on building the images and another 15m in testing.
Well, in that case you're just shooting yourself in the foot. Local mirrors for OS data is about as fundamental a thing as you'd want for provisioning, and in this day of TB of space everywhere there's no reason not to use one.
I haven't timed installs because I don't have split-second needs, but 2m sounds about right except for any local logic being doing in %post.
Posted Jan 16, 2019 19:45 UTC (Wed)
by johannbg (guest, #65743)
[Link]
It should not matter how many or few are maintaining a component, an module, a spin, edition whatever, since it's actively being worked on and maintained.
What matter is knowing which components,spins, modules are not being maintained so that distribution deadweight can be removed and you most certainly dont need to go outside the community for that information, you can simply file a ticket with infra for that.
But let's say for arguments sake the distribution tracking stalker rapes fedorians privacy to obtain that information to have the most accurate usage information in the whole distributions kingdom and knows if there has been increase/decrease in usage and then what?
What is supposingly supposed to be acted upon now which could not have been acted on using the previous method of optaining that "unreliable" information?
Are fedorians gonna get notification spammed from Gnome if they arent participating in the project and just use it?
What's the end game here after that information has been retrived at the cost of Fedora's end user privacy ?
Posted Jan 16, 2019 20:49 UTC (Wed)
by dkg (subscriber, #55359)
[Link] (1 responses)
However, the devil's in the details for how you do "countme". For the sake of the dicsussion, i'll assume that the period of "countme" queries is one per week.
The safest way to do this is for each installation to store the last time it sent a "countme" flag as timestamp lastcounted. When fetching updates, if the most recent Sunday midnight in UTC is later than lastcounted, then send the "countme" flag. When a valid HTTP response is returned from the server, set lastcounted to the current timestamp. This causes all machines to send "countme" at about the same time each week, and avoids per-device identification.
Some fancier proposals which spread the "countme" across different times (e.g. based on hash of UUID, or having them report "countme" as long as it has been a full week since the last time it was sent) offer an additional possible source of tracking and identification of users. So they're more problematic in terms of privacy.
Posted Jan 16, 2019 23:09 UTC (Wed)
by jccleaver (guest, #127418)
[Link]
For install counting, a new anaconda leaf should be added that allows distro/spin counting to happen *once* at install time.
For everyone else, and for counting cloned systems, make the component a separate package. Call it "fedora-census" or whatever.
Firstboot for GNOME/desktop lusers can enable simple (distro/spin counting, with the countme decrement) or *enhanced* telemetry (which uses UUIDs to distinguish). For everyone else, a config file allows this to happen via a fedora-census service. This service should be *DISABLED* by default. (If a cloud/kickstart/image/VM user wants discrete VMs to be counted discretely, they can enable the UUID service.)
Posted Jan 17, 2019 9:41 UTC (Thu)
by Gladrim (subscriber, #45751)
[Link] (21 responses)
Posted Jan 17, 2019 22:58 UTC (Thu)
by johannbg (guest, #65743)
[Link] (16 responses)
This information is only benefitial to IBM/Red hat so it can focus on what it should focus it's resources on...
Posted Jan 18, 2019 15:45 UTC (Fri)
by mattdm (subscriber, #18)
[Link]
Number of systems running, is, of course, just one factor. I don't think there are many people running Fedora Robotics — but the people who do run it do stuff like https://www.electronicspecifier.com/robotics/why-no-one-c..., which is super awesome.
Posted Jan 22, 2019 11:51 UTC (Tue)
by nilsmeyer (guest, #122604)
[Link] (14 responses)
Posted Jan 22, 2019 12:58 UTC (Tue)
by johannbg (guest, #65743)
[Link] (13 responses)
The Fedora is beta platform for Red hat mantra, which dictade and decides the direction of the project and treats it's community as a second class citizen.
What get picked up and works in Fedora ( thus needs to be measuarble in Fedora ) gets integraded into the RHEL stack.
Posted Jan 22, 2019 17:30 UTC (Tue)
by jccleaver (guest, #127418)
[Link] (12 responses)
Except this is distro implementation level stuff. Presumably RH already knows how many server, VM, or (God help you) Desktop systems you're running since you're paying licenses for it, even if you're not using RHN for lifecycle management.
Posted Jan 22, 2019 21:59 UTC (Tue)
by johannbg (guest, #65743)
[Link] (11 responses)
And as things are evolving ( everything is being pre-built upstream, flatpacks, docker images etc ) there is always becoming less and less incentive for end users even administrators who need to start clinching themselve to cloud solution to make a name for themselves in related communities ( they participate in ansible galaxy not ansible in Fedora right ) to partake in downstream distributions.
Being first is something that Fedora has not been for years, The features are nothing more than those that Red Hat pushes fourth, The only real freedom you have is to choose whether you partake in the distribution or not so the only remaining things of the foundation that Fedora was built upon is friends.
What once was a birth mark has grown into a tumor because the balance between Red Hat's involvement and the community has been tipped too much in favour towards Red Hat, something I warned Denise about would happen if she would throw more Red Hatters at the problem as opposide to say no you have find ways to make due with what you have, get the community rise to the occation when Red Hatters came running to mommy begging for more resources.
It's a fine line to keep in check so that either of these forces dont dominate the other.
Posted Jan 22, 2019 23:37 UTC (Tue)
by pizza (subscriber, #46)
[Link] (8 responses)
Um, hasn't Red Hat has always provided the lion's share of the funding (and thus, developers) working on Fedora?
Don't those who do the actual work (or pay for it) ultimately get to set the direction of that work?
It's not like FHEL & Fedora are the only games in town; there's plenty of distribution-level competition, encompassing a wide spectrum of focus, release, funding and governance models.
Posted Jan 23, 2019 1:24 UTC (Wed)
by jccleaver (guest, #127418)
[Link]
Well, yes and no. Corporate world is RPM-based. Developers love the Debian/Ubuntu ecosystem. Embeddeds have their own needs.
If we had stronger competition in the RPM ecosystem, I think whatever Fedora ends up being would be a stronger project. Instead we have this weird process of passive-aggressive interaction where the distracted flagship community project is not functioning as a reliable steward.
Posted Jan 23, 2019 6:14 UTC (Wed)
by johannbg (guest, #65743)
[Link] (4 responses)
I most certanly disagree but if it's corporate that allows for other to get involved without interference with it's products until the corporate takes interest in your work, in which they either take over your work by overwhelming you with workforce or simply buy it or out it out if does not align with said corporate vision, with end result being always the same. The corporate will take it from here, then I agree with you.
Quite frankly i'm amazed that lawsuit hungry colonists that the Americans are, that Red Hat has not been suit over an violation of the consumer act regarding Fedora there in the states but then again i'm not a laywer...
Posted Jan 23, 2019 12:20 UTC (Wed)
by pizza (subscriber, #46)
[Link] (3 responses)
Everyone participating in Fedora, or indeed any other community, is acting in their own self-interest. I don't mean they're out to screw others in the process, but rather that they are getting something they value out of it.
Meanwhile. Have you ever participated in any sort of formal organization? Those who participate get to dictate what goes on. And those who have the most time/energy to contribute particpate the most. And who has the most time/energy? Those paid to particpate. (Because participating doesn't take time away from such mundane things like feeding their families..)
> I most certanly disagree but if it's corporate that allows for other to get involved without interference with it's products until the corporate takes interest in your work, in which they either take over your work by overwhelming you with workforce or simply buy it or out it out if does not align with said corporate vision, with end result being always the same. The corporate will take it from here, then I agree with you.
It's Free Software. If you have a problem with (certain) others using it, or building on it in a way you don't like, then you should have released it under a different license.
> Quite frankly i'm amazed that lawsuit hungry colonists that the Americans are, that Red Hat has not been suit over an violation of the consumer act regarding Fedora there in the states but then again i'm not a laywer...
Winning a suit requires demonstrating someone has been tangibly harmed. I'm having a hard time seeing the harm RH has caused. And, for that matter, even the someone.
Posted Jan 23, 2019 13:22 UTC (Wed)
by johannbg (guest, #65743)
[Link] (2 responses)
Fedora is falsely being advertised as something it's not which could constitute as deliberate deception on Red Hats belhalf.
And there are alternatives than forking off.
Or now that IBM is at the helm it could do something that Red Hat never could or even might have too so it's own products dont get the same treatment as the community made once. ( IBM could make things worse, only time will tell )
Posted Jan 23, 2019 16:16 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
It's only a difference of degree.
> And there are alternatives than forking off.
Of course. But *every* alternative, including a fork, requires a substantial (and sustained!) increase in time, effort, and money from non-RedHat folks. To pretend otherwise is nothing short of delusional.
> Red Hat could publicly admit that this is the case or it could change it's involvement in a manner in which the community is not treaded like second class citizens.
What would that entail, exactly? Red Hat no longer funding developers and infrastructure for the things they care about? Or are you honestly trying to say that folks (regardless of who signs their paycheck) should be forced to work on things they don't care about? (Keep in mind that handing over a paycheck tends to greatly increase the likelihood of someone caring)
Posted Jan 23, 2019 18:30 UTC (Wed)
by jccleaver (guest, #127418)
[Link]
And this is the crux of the problem. Forking Fedora is a lot of time, effort, and money to achieve -- an unknown purpose. There's only one Rawhide, and there's only one central upstream for RPM systems. And, again, people use RHEL for reliability and scale. Forking Fedora and try to make a new RHEL out of it (with all the certifications, process, vendor support, etc) would be basically pointless.
Forking EL (either as a rebuild of RHEL in parallel with CentOS, or a rebuild of CentOS) might make more sense (it makes sense for Oracle, and Amazon), but now you're three steps removed from being able to influence any low-level changes in the upstream. You can barely get devel@fedora to care about EPEL these days, so you can be sure derivatives will... continue to be told to pound sand.
Until the philosophical problems with Fedora/Rawhide/RHEL and CentOS/*EL are solved, which really requires an Official Red Hat Plan Of Action, as the organization behind all three*, there's no easy way for an outside team of a few motivated people to have a real impact on the ecosystem by forking. And so here we are.
(*Red Hat itself is the one entity that could "fork Fedora", both morally and practically, if it felt that restarting the project was for the best.)
Posted Jan 23, 2019 6:36 UTC (Wed)
by zdzichu (subscriber, #17118)
[Link] (1 responses)
Posted Jan 23, 2019 7:52 UTC (Wed)
by johannbg (guest, #65743)
[Link]
Then there is the fact ( despite misleading mailinglist title ) that there exist no Fedora developers other than those that work or contribute in maintaining the project and associated infrastructure.
The seperation in the role of packager was created, to keep the two different dialogs ( policies vs maintainances ) about packages in the distribution seperated.
Every distribution are made up of ( more or less the same ) upstream components which is the place where the actual development takes place. Not downstream.
You can even extend this further, the only seperation between *nixes as in linux,bsd and solaris takes place in the core/baseos, the rest is more or less the same applications or application stack running on top of those core/baseOS stacks.
Then those upstream components are glued together with the base/coreOS for the relevant *nix, runtime policies are made and new distribution and associated religion is born.
Waisting tremendous time and energy in people own lifecycle for no apparent gain other than maintaining nothing more than collective eco.
Posted Jan 23, 2019 1:20 UTC (Wed)
by jccleaver (guest, #127418)
[Link] (1 responses)
We're coming at this from opposite sides, but I agree with you that the current implementation of Fedora Project is not working. "Red Hat Linux" was a wonderful thing, and opening "Red Hat Linux" up to community involvement with a derivative functioning as the funding for it all seemed reasonable enough ($34B of reasons, really). But whatever the Fedora Project has been trying to be distinct from that has failed.
> What once was a birth mark has grown into a tumor because the balance between Red Hat's involvement and the community has been tipped too much in favour towards Red Hat, something I warned Denise about would happen if she would throw more Red Hatters at the problem as opposide to say no you have find ways to make due with what you have, get the community rise to the occation when Red Hatters came running to mommy begging for more resources.
There are people that really want *Fedora* (the Desktop distro) to succeed in the distro wars. I don't. I couldn't care less about *Fedora*... I haven't used it for anything meaningful since Core 5. I care a great deal about RHEL and its derivatives, and Red Hat provides the process used to take Fedora and make a reliable, engineered, released product out of it. Fedora's missteps affect EL users.
I want what's best for the Red Hat ecosystem -- for basically any Linux distro that's RPM-based. If it takes throwing Red Hatters at the problems in the Fedora Project, so be it.
Posted Jan 23, 2019 7:00 UTC (Wed)
by johannbg (guest, #65743)
[Link]
This needless fragmentation between linux distributions only exist on religious,philosophical level and the associated needless deviation that has seperated the distribution on component level as an result of that needs to be stopped ( on the core baseOS level atleast ).
Red Hats plays it's part in keeping that from happening by holding death grip on the /etc/sysconfig directory ( which should have been eliminated in Fedora by now ) , inconsistent naming in components between distributions, ( people can be as religious as they want which package manager is best or whether to use one and innovate in that area, just keep the package names consistent between distros ) etc.
With regards to epel, epel should have never existed in Fedora no more than modularity has any place in Fedora today, tomorrow, ever.
Both of these effords belong in distributions which are based on RHEL not Fedora which naturally puts it in CentOS these days, after Red Hat aquired it and it's community along with it.
Posted Jan 18, 2019 15:38 UTC (Fri)
by mattdm (subscriber, #18)
[Link] (3 responses)
Posted Jan 20, 2019 15:48 UTC (Sun)
by archbtw (guest, #129959)
[Link] (2 responses)
Posted Jan 20, 2019 19:02 UTC (Sun)
by mattdm (subscriber, #18)
[Link] (1 responses)
Posted Jan 20, 2019 23:26 UTC (Sun)
by archbtw (guest, #129959)
[Link]
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
* Metrics on how many systems are short-lived (e.g. testing environments) vs long-lived and/or upgraded vs. freshly installed.
* Rough metrics on user counts that are a better approximation than the current guesses at the mirrorlist hits.
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
$ cat /usr/lib/NetworkManager/conf.d/20-connectivity-fedora.conf
[connectivity]
uri=http://fedoraproject.org/static/hotspot.txt
response=OK
interval=300
```
Fedora, UUIDs, and user tracking
* Identifying which Edition, Spin or Lab is in use (this information isn't transmitted and also this package is only installed on the Workstation Edition by default; it's not really useful on Server or Cloud)
* Identifying whether the system is short- or long-lived (this information also isn't transmitted)
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
> We document how you can disable it if you're so inclined (read: paranoid).
clue: when it's not opt-in it's a $cam
We document how you can disable it if you're so inclined (read: paranoid).
You shouldn't have used of the slur 'paranoid' there if you are really trying to be an honest broker in this debate.
clue: when it's not opt-in it's a $cam
clue: when it's not opt-in it's a $cam
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
I disagree. The project could push out tracking to as many users as possible and deal with the (well-known) consequences, *or* it could simply notice whenever a proposal is so bad it sparks flame wars across the entire internet and change course.
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
You don't need to keep doing the test *if nothing changes*. If something does change, then you don't *know* that failover will still work the way you think it will, and the only way to be sure is to test it again.
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
> Would be faster probably if I bothered to run internal mirrors but then I would have to mirror 4 distro's ( Arch,Debian,Fedora,OpenSuse ) and different releases of those distro's but thats not high on my priority list thou that might change if fedora is about to track it's user base...
Fedora, UUIDs, and user tracking
Lennart's "countme" flag proposal is far better than any of the uuid proposals.
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
An skill that Red Hat or someone(s) understood and had mastered within Red Had and made what Red Hat is today, an skill that Red Hat has lost ( atleast with regards to Fedora ) or those that had it moved to build communities somewhere else *cough* Ansible *cough*...
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
It's not the only option as you make out to be.
Red Hat could publicly admit that this is the case or it could change it's involvement in a manner in which the community is not treaded like second class citizens.
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
> Of course. But *every* alternative, including a fork, requires a substantial (and sustained!) increase in time, effort, and money from non-RedHat folks. To pretend otherwise is nothing short of delusional.
Fedora, UUIDs, and user tracking
RH pays for almost all the infrastructure, though.
Fedora, UUIDs, and user tracking
Leading to this happy life fulfilling cheers and joys of various upstreams having to deal with this needless downstream distribution deviation mess...
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking
Fedora, UUIDs, and user tracking