Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
I don't believe the technical details are as significant as the systemtic change to the boundaries of trusted software maintainers. Consider this comment, which appears to be the core justification: Michael Catanzaro wrote: > > Flatpaks already take precedence over RPMs, and there are no plans to > change this for the reasons I mentioned in my previous mail regarding > sandboxing, which is more important than other considerations. A sandboxed trojan application is still capable of damaging the user's security, even if it can't damage the system's security. To illustrate the difference, a subverted browser can share all credit card details seen (user's security compromised), but removing that software removes the subversion (system security not compromised) A preference order of Fedora Flatpak > GNOME Flatpak > Fedora RPM makes user's security of graphical applications reliant upon a wider set of trusted software maintainers than Fedora Flatpak > Fedora RPM > GNOME Flatpak Essentially, for graphical applications the change makes Fedora trust and security processes approach the minimum of of Fedora trust and security processes and GNOME trust and security processes. That's change to the security stance of the distribution which requires explicit discussion prior to accepting the change. -glen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RFC: Change the default hostname for Fedora 26+
> RFC 2606[1] reserves several TLDs that may never be registered for > public usage. Out of those, going with > Fedora-.localhost > seems like the best bet. The *reason* localhost is a reserved name is to discourage its use in DNS names. Your proposal is the opposite to that intended by RFC2606, something which the casual reader of your message may have missed. -glen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: nss_myhostname as default in Fedora
> It's part of what nss-myhostname provides. There's clearly no > consensus on the "gateway" feature. The belief of operating systems' programmers that a lack of a default gateway must imply no network connectivity constricts useful network designs. My objection to the "gateway" name is simply that "ping gateway" gives applications another way to test this incorrect belief. -glen -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F21 Self Contained Change: Remote Journal Logging
I am pretty sure HTTP(s) is the right choice Hi Lennart, The choice of HTTPS does complicate the network infrastructure moving log records into a network management QoS class (ie, making sure that remote logging works during a DoS attack caused by malware). If you feel that HTTPS is the correct protocol then please consider using another port number than 443. Cheers, glen -- Glen Turner http://www.gdt.id.au/~gdt/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: No Default Syslog
Hi Lennart, I suppose someone should mention small flash-disk-only computers. There traditionally we fling syslog messages to the serial console or a LRU buffer in RAM (often the dmesg buffer). The point is to avoid I/O on the flash memory. Syslog daemons tend to do a lot of fsync-ed I/O, which just chews up flash write cycles. With some configuration the syslog daemons can be made to not to fsync, and with additional configuration to write to the serial port or to the dmesg ring buffer. These small computers aren't specialised embedded systems anymore -- if you buy a cheap ARM-based laptop then you are buying a such a system. Their increasing popularity is very much the reason ARM is becoming a top-teir architecture in Fedora. These systems are *cheap*, so they don't have the write cycles of an expensive SSD. I'm not across journald at all. But the questions in my mind are: - Is is possible to run journald without writing to disk; that is: to serial as text, or as binary to a ring buffer which can then by used by journalctl? - When writing to disk does journald fsync, and if so can that be disabled by a non-guru laptop user? - Is journalctl available from the dracut shell, so that we can get bug reports for early system failures? There is a lot more variation in small computers, and thus more early system failures. Thank you for making the binary format portable between computers. Allowing a 32b ARM journal file to be displayed on a x86_64 desktop is very useful. Thank you for your time, glen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
On 24/06/2013, at 9:00 PM, Chris Adams wrote: Once upon a time, Glen Turner said: What we don't want is a scenario where configuring these protocols on servers has to be done by network engineers. We want them configured from a GUI and supervised by a master daemon. Let's call that NetworkManager. You think hundreds of servers (with untold numbers of VMs), or any complicated networking setups, are going to each have their network configuration managed by a GUI? In that case I think the sysadmin will do what they do now. Run the GUI on their development box, look at the underlying NetworkManager configuration files it created, generalise them, and then farm them out using puppet. What I am arguing against is the current situation where a server administrator has to configure each element of a network configuration, in one configuration file per protocol. It's bad enough as it is now, without data centre networking exploding the number of protocols seen by a VM host. The router experience has been that per-protocol configuration is a dead end. The lesson appears to be that it is better to deploy software which directly addresses use-cases (thus explaining some of the hype around OpenFlow). I see NetworkManager as the best tool to do that job on Linux. To deploy a new network service you deploy the NetworkManager plugin, its dependencies, and a lightweight configuration file written by the NM GUI. I'd hope for a plugin ecosystem, since the number of use cases, and the variations on those, is pretty large. With a use-case approach rather than a protocol configuration approach junior sysadmins don't also need to be network engineers in order to deploy networking features -- ranging from a protocol nightmare like MPLS-based data centre networking; to anycast networking for DNS; to IPVS and HA failover. This sort of mechanism also gives the opportunity to promote good practices which aren't done because they are too hard: such as placing management traffic in a preferenced tc class which will allow device management connectivity during a DoS, or running LLDP on physical interfaces to allow simple discovery of cabling mistakes; from the sysadmins point of view they just enable those plugins. Note that these are runtime plugins -- not configuration-time wizards -- if you have multiple plugins requiring the services of the BGP protocol then they should both succeed. -glen -- Glen Turner http://www.gdt.id.au/~gdt/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
On 21/06/2013, at 4:28 AM, Dan Williams wrote: It's supported that for 4 or 5 years. You don't need aliases at all, Consider an anycast service where the alias interface reflects the availability of the service on the server. An OSPF or BGP daemon then advertises the address of the alias interface into the network. You want to be able to up/down the alias interface independently of the other addressing on the physical interface. You don't want to remove the addressing -- from a the routing daemon's point of view there's a considerable difference between no addressing (an error) and down (a state). And sure, this isn't a common desktop scenario. But as NetworkManager makes its way into servers... -glen-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
On 21/06/2013, at 10:31 PM, Chris Adams wrote: Current network information is available from the kernel and doesn't require guessing. Why would you code something to talk to some random daemon API (that may change) when you could talk directly to the source via the kernel netlink API? The classic here being applications which look for NM messages to indicate that networking connectivity is available rather than waiting on the presence of non-directly connected routes in the routing table. -glen-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
On 22/06/2013, at 7:23 PM, Richard W.M. Jones wrote: (2) Write a shell script that contains the ifconfig/route add (or ip ...) commands they need and have it run at boot. Most simple static network configs are 2 or 3 commands at most. If you have a server in the tradition of UNIX workstations sure. But such simple networking isn't the case for some servers today, and it's hard to see that it will be the case in the future. Sun's tagline of the network is the computer was true. But for servers these days the computer is the network is also the case. It's nothing for a server today to statically NAT or bridge IPv4 to VMs. Even in that case it's best if the guest VM picks up its IPv4 addressing using DHCP. But in the future we'll want to do better than that: to move network routing onto the server itself. These new data centre ethernet protocols are not entirely implemented in kernel space. Some run quite complex BGP and MPLS control planes; others run IS-IS control planes. The ethernet link itself isn't remaining a simple thing either. Once you're running a few hundred servers then management protocols start to pay their way: LLDP (what server is on this switch port?), ethernet OAM (help, the cable is running errors). What we don't want is a scenario where configuring these protocols on servers has to be done by network engineers. We want them configured from a GUI and supervised by a master daemon. Let's call that NetworkManager. Now maybe Dan hasn't quite realised what he's signed up for here. But then again, there was a time when I despaired of Linux ever working with a 3G modem, whereas today it offers the best experience of all the operating systems. -glen -- Glen Turner http://www.gdt.id.au/~gdt/-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
Kickstart is fine for centrally managed devices. They've got experienced sysadmins who don't mind getting dirty with configuration files. The real kicker is people who manage their own device: not just BYOD but also part-time sysadmins who can't run the corporate distribution. These people can suck substantial time from deep support at the help desk. For those people there does needs to be an easy way for them to configure a network authenticating account. But there's no need for that to be in the installation dialogues. Considering that IT support might approach them well after installation and say our policy is that machine authenticate against the Corporate Blah rather than have local authentication there's a strong argument for being able to do this well away from installation. I'd also strongly encourage a design which makes it easy for a corporate-issued RPM to configure the authentication. For an example of something wonderful, NetworkManager has a one-file-per-ssid design so its easy for a RPM to drop in the configuration files for the corporate wireless. I'd really like a company to be able to have a set of noarch RPMS which put in place the minimum configuration for use within the organisation. -glen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [announce] yum: parallel downloading
On 21/05/2012, at 5:12 PM, Zdenek Pavlas wrote: Three connections limit is used when the above is not available (e.g. a baseurl setup with just one mirror). I don't mind lowering it to just two, as that should work good enough in most cases. Yes please. Two is better than three from the server's point of view. Yum doesn't put in the HTTP header (say, appended to User-Agent) why it decided to use our mirror, so we have no count of the sites or users which manually set baseurl or give our mirror's name to anaconda. Mailing list postings often recommend this when people complain of slow or expensive downloads. -- Glen Turner http://www.gdt.id.au/~gdt/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [announce] yum: parallel downloading
On 19/05/12 01:04, José Matos wrote: The total number of connections should be the same, as far as I understand only the number of connections from a single host will be three. The risk is the rise in the maximum number of concurrent connections. A server happily supplying 50,000 concurrent connections should not be assumed to remain happy at 150,000 concurrent connections. Since it should be safe to assume that the downloads are independent events then there should not be any significant difference for busy servers. :-) I am afraid that I have missed your point here. I am somewhat blinded by the use of the word independent. I have a statistical background and that word carries a meaning similar to unrelated. Perhaps you could state your argument with more explanation Thank you, Glen -- Glen Turner www.gdt.id.au/~gdt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [announce] yum: parallel downloading
On 17/05/12 01:37, Zdenek Pavlas wrote: - mirror limits are honored, too. Making many connections to the same mirror usually does not help much, it just consumes more resources. That's why Yum also uses mirror limits from metalink.xml. If no such limit is available, at most 3 simultaneous connections are made to any single mirror. Hi Zdenek, Why is the default three connections rather than one? Is a tripling of the number of connections to a mirror on a Fedora release day desirable? Consider that a large mirror site already sees concurrent connections in the multiple 10,000s. Cheers, Glen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNS 3 http://www.gns3.net
On 15/05/12 07:21, Colin Stubbs wrote: These are what I've fiddled with/created and am currently using for FC16/x86_64, ... http://www.routedlogic.net/files/dynamips.spec You might want to add the patch for multiple idlepc values. This makes a big difference in practice. As far as Fedora's policy Packages which are not useful without external bits note that there are repositories such as rpmfusion with less strict inclusion criteria. Perhaps your package would be happier there, whilst still making it easy for Fedora users to install GNS3. Note that Cisco is not the world's only networking vendor and some other vendors make their software available as a VM image for evaluation and learning. You might add the ready availability of learning platforms to the Request for Tender the next time you make a major networking purchase. -- Glen Turner www.gdt.id.au/~gdt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]
On 11/05/12 00:30, Adam Jackson wrote: So the set of people we'd be inconveniencing is exactly the set of people with no bandwidth and the inability to boot from anything larger than a CD. The way forward for those cheap machines on cheap networks is to let them boot from CD but to then pull most of the installation from USB hard disk or flash. I believe that this amounts to little more than a better description in the documentation. As for your question about numbers, the high end machines coming through my local PCs for the poor refurbisher (www.aspitech.com.au) have DVD-ROM drives (ie, even those more expensive machines can't write a DVD image, but can write a CD image). So this isn't only a third-world issue, but one faced by anyone trying to get Linux running whilst on low income. -- Glen Turner www.gdt.id.au/~gdt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: urandom vs haveged
The risk is reading unused blocks using the drive's hardware. Those unused blocks may contain user data, operating system state, or a covert channel allowing data or state to be inferred. The response is to overwrite all of the disk with some value. The random number generator is a higher risk means to provide that value than writing a fixed value. Firstly, it is difficult to test that the operation has succeeded. Whereas the operation of writing a fixed value is simple to verify. Secondly, the operation of the random number generator itself is difficult to test. In general, non-cryptographers see random numbers as some sort of magic sauce whereas cryptographers see random numbers as a lever to crack open the machine state. Random numbers are invaluable for forcing attackers to search an entire state. But where they are not needed they should not be used, since if you don't provide a lever than an attacker can't push against it. Keeping a large sample on permanent storage of random numbers generated by that very machine is providing a very large lever to push against any flaw. -- Glen Turner http://www.gdt.id.au/~gdt/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On 2012-03-15 Dan Williams wrote: The only effect this checking will have is to change NetworkManager's state from CONNECTED_GLOBAL to CONNECTED_SITE or CONNECTED_LOCAL. It doesn't do anything odd like disconnect and retry some other connection, which wouldn't make much sense. It just changes some state which apps can use to figure out whether they'd connect to say your IRC server or your email or whatever automatically. Hi Dan, I suggest that is something the application should determine, not NetworkManager. Take the case where a ISP loses international connectivity, then a NetworkManager-informed application won't connect to the in-country ISP's IRC/e-mail/... server even though those servers are available. Thus connectivity detection worsens a partial loss of connectivity into a full loss of connectivity. The app has to be able to handle no connectivity anyway: just because Network Manager can HTTP GET the URI doesn't mean that IRC works. For example, a corporate firewall could allow HTTP but block IRC. Both the end-to-end argument and occam's razor argue for the application gracefully handling no connectivity. The current situation is that many apps don't handle a lack of connectivity with grace. But I suggest that this isn't NetworkManager's problem to solve. Even the current situation isn't great. NetworkManager shouldn't be telling applications that the network is available. That DBUS message should be triggered by the insertion into the main forwarding table of a default route. Then any source of global connectivity will set the app connecting (NM, NM work alikes, ip route add, ospfd, tunnels, etc). Best wishes, Glen PS: I really don't understand the operation of dnssec-triggerd. The paths for HTTP and DNS traffic through an enterprise network can be very different so testing one protocol doesn't say a huge amount about the availability of the other protocol. But then I don't even understand the desirability of that program: allowing an external event (eg an access list on a router or a DoS attack) to trigger a reconfiguration from a DNSSEC-validating to a non-validating configuration seems more of a security bug than a feature. But I'm likely missing something here. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice: IPv6 breaking issues tentatively considered blocker for F17
Hi, I am the network engineer at Australia's Academic and Research Network responsible for assisting the deployment of IPv6 across Australian universities. Your posting was bought to my attention. Your phrasing of the condition for blocking is pretty broad: there are lots of ways to break IPv6, just as there are with IPv4, and just as with IPv4 not all of them are significant enough to be blocking. Can I suggest the following as a starting point: - failure in configuration of interface addresses with a link scope address via stateless address autoconfiguration should block - failure in configuration of interface addresses with a global scope via stateless address autoconfiguration should block - failure in configuration of interface addresses with a global scope via manual configuration should block - failure in configuration of DNS forwarding via stateless DHCP6 should block - failure in configuration of DNS forwarding via RAs should block - failure of connectivity of network ::1/128 (localhost) of all services should block - failure of unicast or multicast connectivity of link local addressing of allowed services should block - failure of unicast connectivity of global addressing of allowed services should block - failure of connectivity of ICMP6 service for codes = 127 should block Non-stateless DHCP6 is primarily used by ISPs to configure customer routers. Those routers present SLAAC to their downstream users. Non-stateless DHCP6 is also used by enterprises who wish to parallel their existing management of computers via IPv4 DHCP into IPv6. In my view that is a poor network design choice, but there is no denying that it is a choice made by some enterprise networks. At this point in time you could deploy a IPv6 with manual configuration and with SLAAC (with both stateless DHCP6 and RAs to configure DNS) and make most people happy. The significance of the proportion of people made unhappy may or may not be enough for a release blocking bug (as opposed to simple lack of support for that IPv6 feature) -- that's really your choice. It also depends if statefull DHCP6 host configuration was supported in a previous release, in that case a regression leads to such a complicated scenario for network engineers and systems administrators that the bug should be release blocking. Cheers, Glen -- Glen Turner http://www.gdt.id.au/~gdt/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Access rights for system logs
On Sun, 2011-02-27 at 23:20 +0100, Till Maas wrote: On Sun, Feb 27, 2011 at 12:30:43PM -0700, Kevin Fenzi wrote: Were you thinking of just /var/log/messages? or all log files? Or all syslog written files? or ? If you are talking all log files, I would suggest making this into a feature for f16, since it's going to require coordinating a bunch of changes of packages to have the right group ownership of their log files. It is only required for log files that are not world-readable. ... The existence of /var/log/secure suggests that the policy is not as simple as one group owning all file files. -- Glen Turner www.gdt.id.au/~gdt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
