Slashdot Mirror

See also: FreeOTP

Time-based one time password. For example, see FreeOTP (sponsored / published by Red Hat, compatible with the Google Authenticator)

FreeOTP https://play.google.com/store/... https://fedorahosted.org/freeo...

Somewhere along the line, about when Fedora's Anaconda installer UI was redesigned, Fedora introduced an information theoretic password strength meter that measures apparent bits of randomness.

Here it is in use in the Anaconda source: https://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/users.py#n130

Here is its official site: https://fedorahosted.org/libpwquality/

It would appear this information theoretic meter has made its way into Ubuntu and Arch.

Somewhere along the line, about when Fedora's Anaconda installer UI was redesigned, Fedora introduced an information theoretic password strength meter that measures apparent bits of randomness.

Here it is in use in the Anaconda source: https://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/users.py#n130

Here is its official site: https://fedorahosted.org/libpwquality/

It would appear this information theoretic meter has made its way into Ubuntu and Arch.

Unfortunately, Mukt completely mis-reported this and Slashdot picked up their errors for the summary, which is making for a lot of confusion.

tl;dr:

1. blivet-gui isn't supposed to (and in fact cannot) 'replace' gparted in any reasonable sense of that term.
2. blivet-gui is a new application, but its backend is the Fedora installer's storage management code, which is a very old codebase. There is no new storage management backend being written here.
3. Lennart and systemd have nothing at all to do with this.
4. It wouldn't really be practical to 'contribute' this to gparted, as it would involve completely ripping and replacing gparted's backend and then very rapidly proposing significant changes to the GUI, and hence would be a project takeover by any other name.
5. blivet uses standard underlying tools for performing operations, it's just a logic/configuration layer for them.

1: what the original announcement says is that blivet-gui uses a gparted-like UI to make it instantly familiar for gparted users. It doesn't say anything at all about it 'replacing' gparted. That's a pure invention (likely based on a misunderstanding) in the Mukt article. See the original announcement at https://lists.fedoraproject.or... to verify this, if you like. There's no sense in which blivet-gui really *could* "replace" gparted, if you think about it. gparted is an independent project; Red Hat doesn't own or maintain it, so Red Hat can't stop it existing or being maintained. gparted isn't a significant component for either RHEL or Fedora: it's just a leaf package, an app like any other. It's not like anaconda uses gparted as its partitioning tool, or anything like that. So talking about blivet-gui 'replacing' gparted doesn't make any sense, not upstream, not downstream. So long as upstream gparted devs see a need to keep developing gparted, gparted will continue to exist upstream, and so long as a Fedora packager wants gparted to be in Fedora, it'll be in Fedora, whether or not blivet-gui or any *other* storage management GUI app is also in Fedora. We have lots of space in the repos.

2: the backend for blivet-gui is blivet: https://git.fedorahosted.org/g... (packaged in Fedora as python-blivet). This codebase is simply the storage management backend of anaconda (the Fedora installer) split out into its own repository. The split happened back in 2012: http://www.redhat.com/archives... . The intent was to allow for exactly this kind of code re-use. So there really isn't some kind of new NIH effort going on here: the storage management code is not new, all that's new is the light wrapper around blivet to produce a standalone GUI app rather than using it as a part of the anaconda installer. The underlying codebase has existed basically as long as anaconda has existed, which is rather longer than gparted has existed. anaconda dates back to 1999 (https://fedoraproject.org/wiki/History_of_Red_Hat_Linux ), gparted AFAICT dates back to 2004 (http://gparted.org/news.php?item=180 ).

3: Doesn't really need expanding on, but no, there is absolutely zero link to Lennart, systemd, or any other systemd developers.

4: so the reason to do blivet-gui at all, and the reason anaconda doesn't just call gparted for "partitioning" like ubiquity does, is it doesn't cover anywhere near the functionality we actually need for the Fedora (and, more to the point, RHEL) installer. gparted really is a *partitioning* tool, and there's a reason I keep referring to blivet as "storage management". It handles things that aren't just partitions. The most obvious examples are mdraid, LVM, and btrfs (insofar as btrfs acts as a volume management and redundancy system, not just as a simple filesystem like ext), but blivet has all sorts of other interesting capabilities too, primarily of interest t

It is based on the blivet storage management library:

https://github.com/dwlehman/bl...

Which is also used by the Anaconda Fedore/Red Hat Enterprise Linux installer:

https://fedoraproject.org/wiki...

And Open LMI:

https://fedorahosted.org/openl...

But it might indeed use libparted to create the actual partitions.

I don't have hard data yet, but I'm finding that EL7 is much much faster than EL6 on the same hardware for the workloads I've tried so far.

I don't know that tuned is most responsible, but I can see that it's running and that's what it's supposed to do.

I realize that the kernel is better and perhaps XFS helps, but those alone seem insufficient to realize the difference.

Anyway, it's somewhat along the direction people are talking about, even if only minimally.

This isn't really a policy.

The specific case arose, FESCo asked Fedora Legal for it, Fedora Legal asked for expert opinion from Red Hat's lawyers, and the guidance that came back was posted to the FESCo ticket and meeting log. That's it. It's a case where a general project committee asked for expert legal guidance.

You can read basically the entire thing happening at https://fedorahosted.org/fesco... .

https://git.fedorahosted.org/cgit/anaconda.git/commit/?id=da565b769979a031f318dbc727b9888e4f1fb37c

"Revert "Add signal handlers for controlling password entry visibility." (#958608)."

A lot of this conversation has been about remote security scans, but once you find a vulnerability, how do you remediate it? How do you maintain your security posture, and continue auditing your hosts on a regular bases? To what standard?

The National Institute of Standards & Technology provides a lot of help to those attempting to implement security standards.

First is the Security Content Automation Protocol (SCAP) - scap.nist.gov. This defines how you manage, measure and evaluate vulnerabilities.

Second would be SCAP content. You'll note on the NIST SCAP page the word "community" appears 5 times in the first paragraph. That's not on accident. SCAP content is generally community generated, and there are lots of great lists of people working on SCAP content for a variety of operating systems.

Red Hat maintains the gov-sec mailing list and fedora, for example has loads of content available for Red Hat Enterprise Linux based systems.

Our friends at NIST also publish what is called the US Gov't Configuration Baseline (USGCB for short). USGCB content is available in SCAP format for Windows & RHEL. These standards are certainly a good starting point.

If your standards come in the form of a STIG - that content is available as well from the Aqueduct project.

[Disclaimer - I work for Red Hat, I support the US Gov't, and I think making security easier is probably an important thing to do]

A lot of this conversation has been about remote security scans, but once you find a vulnerability, how do you remediate it? How do you maintain your security posture, and continue auditing your hosts on a regular bases? To what standard?

The National Institute of Standards & Technology provides a lot of help to those attempting to implement security standards.

First is the Security Content Automation Protocol (SCAP) - scap.nist.gov. This defines how you manage, measure and evaluate vulnerabilities.

Second would be SCAP content. You'll note on the NIST SCAP page the word "community" appears 5 times in the first paragraph. That's not on accident. SCAP content is generally community generated, and there are lots of great lists of people working on SCAP content for a variety of operating systems.

Red Hat maintains the gov-sec mailing list and fedora, for example has loads of content available for Red Hat Enterprise Linux based systems.

Our friends at NIST also publish what is called the US Gov't Configuration Baseline (USGCB for short). USGCB content is available in SCAP format for Windows & RHEL. These standards are certainly a good starting point.

If your standards come in the form of a STIG - that content is available as well from the Aqueduct project.

[Disclaimer - I work for Red Hat, I support the US Gov't, and I think making security easier is probably an important thing to do]

...something of a subnote (not so small as a netbook, 10-12" panel is fine, 14 at a push). My kids loved K12LTSP/Fedora as a platform, it's cram packed with educational software, games and your usual desktop environment stuff; what it'll run on these days is pretty much what other people are binning because they can't get Vista running on it!

Puppet combined with either Foreman or Cobbler

The kids will be grateful later on for the opportunity to break out of MS lock-in, and Python is a fun, easy language to learn, though surprisingly powerful. Design the classroom so that a pair of students (as in pair programming) sit opposite each other so they can look each other in the face, not each others monitor. Give assignments per pair, not the same assignment to the whole class. Use source-code control. (So you can check on their progress after class). Give them assignments that span several school-hours, to occupy them. Not just stupid hello world/word counter programs that are too boring and don't do anything useful. Design the classroom so the pairs all see the whiteboard/projection place, yet have space enough to stretch out. Award collaboration (not cheating kind of collab), but also award individual flashes of insight. Do base your CS class on programming as it is a useful skill even for those who won't work as IT people. Meaning really, most of these kids today know how to use word processing and/or spreadsheet software, and if you captivate them with something interesting and fun, they'll be less likely to cause havoc in the classroom. If you must use Windows, somebody mentioned Faronics ... good choice. If you want to go with some fancy stuff like VDI or Thin Client enviroment (which I highly recommend) ... use something like https://fedorahosted.org/k12linux/ or even better the SUSE version http://en.opensuse.org/LTSP because of Yast (management tool, not all powerful, but just enough). Configure thin clients with LXDE or some hybrid containing Awesome WM, deploy Firefox, Thunderbird, Eclipse, OpenOffice (apps that use local workstation resources, but boot over network) and you're be set for another 4-5 years. If you must use Windows, everything here applies but you change the server from Linux Terminal Server Project to this... http://www.xpunlimited.com/ ... and deal with the clients accordingly ... probably with WPKG (http://wpkg.org/). You can do everything, even on a tight budget, you just have to have some imagination, and a good working knowledge in tinkering with various open-source software.

Yeah it's not like any Linux programs bundle internal version of zsync to work properly. Oh wait...

Fedora has components to help manage large deployments. https://fedorahosted.org/spacewalk/ It also has FreeIPA to help with a secure and scalable means of managing authentication/authorization/resources within the cluster. http://freeipa.org/page/Main_Page

You can change the underlying disks - we do this for virt-v2v.

Fixing /dev/disk stuff is just one of the things that makes conversions harder than they should be.

RAID/md is not used much by virtual machines (it's done on the host instead) so I can't comment on what problem you had.

Rich.

Now I begin my bi annual ritual of backing up my data, and making a new live CD

Why create a CD? It's better to use LiveUSB Creator to put the LiveCD bootable image onto a USB flash drive. There's even a nice GUI, works on Linux (of course) or Windows. Here's the How-to..

And 1GB flash drives are cheap and plentiful these days ... if you can even buy a flash drive that small anymore.

I would recommend using pungi and Fedora. It can determine all the prerequisites of the programs you specify and download them as well. Basically, you just use the gather portion and it downloads all the files. I used it for maintain
https://fedorahosted.org/pungi/

You don't do exactly what the project says it does. The project uses diskless system with no ROM OS to boot to a full X session or RDP session. Jim McQuillan basically wrote a system to duplicte what he was doing for hospitals at the time. When I used LTSP often (from 0.9 to 4.0, circa 2000-2004), the process worked like this:

1. PXE boot to find a kernel
2. Get DHCP address
3. load the root file system
4. Pivot root into the new system
5. NFS mount /home
6. Start X session with optional server chooser.
7. Log in to an X session on the server while still being able to use local sound, printers, and USB drives.

I'd also like to give a big shout out to Eric Harrison, who made the whole system easy to use for schools with K12LTSP (now K12Linux).

There are many ways to do the things you describe. I personally make extensive use of Puppet.

This is a great solution for your configuration files, but note (directly) your code. This is where your distribution's packaging system comes in.

Build packages of your code for your OS package manager (be it RPM, portage, apt, whatever... it's usually not that difficult). Give the packages version numbers based on svn revision, if you need that granularity. Create an automated mechanism to build your package and insert it into a local repository.

Tell puppet to ensure that your 'dev' environment is always using the latest package. Tell puppet to ensure that your production and test environments are running whichever specific version they're supposed to be running.

A downside of puppet is that it's a 'pull' based system, by default every 30 minutes. For most situations, this is adequate - but not all. You might also investigate Func as, at the very least, a convenient way to tell a group of notes to phone back home to puppet on demand.

I think that's the modified version there, which references the original version on its SF page.

Based on http://git.fedorahosted.org/git/pam_krb5.git/ it was last updated 6/26. Article poster doesn't give too much detail of the timeline, i.e. how long the original developer was unresponsive.

It took very little Googling to find that the maintainer of pam_krb5 is an active Twitter user, among other things. Either the OP didn't even remotely try to get in touch with him, the original maintainer is on vacation, or there's more to this story such as the OP's patch being something that really can't be merged into the primary repository cleanly.

Fedora is already using binary diffs to speed up downloading updates - see yum-presto. With a better binary diff algorithm, the RPM updates can hopefully be made even smaller. As the Google developers note, making smaller update packages isn't just a 'nice to have' - it really makes a difference in getting vulnerabilities patched faster and cuts the bandwidth bill for the vendor and its mirror sites. Remembering my experiences downloading updates over a 56k modem, I am also strongly in favour of anything that makes updating faster for the user.

Not sure if you care, since it's not Ubuntu directly, but Fedora has done this for at least the past 6-12 months. They have since version 9: https://fedorahosted.org/liveusb-creator/

you might be able to use an ubuntu livecd image with it...?

Regarding the CentOS side, you could try func or if you have an oracle installation lying around, spacewalk.

Spacewalk should have support for PosgreSQL by end of this year.
https://fedorahosted.org/spacewalk/wiki/PathToPostgreSql

In the same time it will probably have support for DEB packages, so you may manage not just Red Hat, Centos, Fedora ... but Debian and Ubuntu as well.
https://fedorahosted.org/spacewalk/wiki/Deb_support_in_spacewalk

Spacewalk should have support for PosgreSQL by end of this year.
https://fedorahosted.org/spacewalk/wiki/PathToPostgreSql

In the same time it will probably have support for DEB packages, so you may manage not just Red Hat, Centos, Fedora ... but Debian and Ubuntu as well.
https://fedorahosted.org/spacewalk/wiki/Deb_support_in_spacewalk

https://fedorahosted.org/func/

I know it's get Fedora in it's name but it's been accepted into as a package into Debian (and thus ubuntu).

It's pretty cool, designed to control alot of systems at once and avoid having to ssh into them all at once, has a build in certification system, a bunch of modules written for it already , usable from the command line so you can easily add it into your scripts and has a python api so if you really wanted some you could throw together some django magic if you wanted a web front end. OpenSymbolic is a webfront end for it already although I haven't checked it out.

Not exactly what you wanted as there's a bunch of work you'd need to do to get it to do the things you want.

It's almost as easy as installing a distribution these days. The Edubuntu project did most of the hard work, so I'd recommend starting there.

Also see K12Linux, which is LTSP integrated with Fedora 10. Haven't tried it, but it's supposed to work well.

Both come with "kiddie" graphics and themes installed by default, but those are easy to change. The software underneath is still standard Linux desktop fare.

you mean spacewalk/satellite http://www.redhat.com/spacewalk/screenshots.html or perhaps func https://fedorahosted.org/func/

Check out https://fedorahosted.org/k12linux/

Okay, I just noticed that they changed some things since I last looked into when I was doing Volunteer work a few years ago, and it is now Legacy, the project is now: https://fedorahosted.org/k12linux/

I can't agree more. I switched over to python for all non-trivial scripting a couple of years ago, and I find it much more pleasant. I even sometimes use iPython instead of bash when I know I'll need to do something complex interactively.

By the way - if you like using python to control systems, you might also enjoy the func project.

Actually, I like none of the above at this time, but Fedora has an interesting project going now where updates will be distributed as just the diff, not an entire redownload of the package and/or the dependencies. *That* project I admit has me interested and will make me stay with them until I can see if it has legs or not, if not, then ya, I'll go elsewhere, Mepis maybe, not sure at this time, maybe even try slack. I always keep a knoppix disk handy as my backup, so there's debian for ya (and it sure has come in handy at times). I tried ubuntu and didn't like it. I've been using rpm based since redhat 7, so I am more comfortable in it, but offered a suggestion (now a few times here) that perhaps the fedora devs and redhat (any of whom might have a good chance of reading such discussions) might reconsider the twice a year release and go to once a year and really concentrate on bug fixing what's been released (that and picking some audio standard and staying with it). Or actually come out with a real home user desktop release with support, charge some dollars for it. Here is the link to this ipdates project, which will be just the shitznit for folks like me on diaolup if they get the kinks out of it. You see that is the major problem, the sheer size of maintaining updates is very hard on dialup, no matter which distro you use at this time. I can milk out a release and not update every six months, but you still have to constantly update even if you are one or two releases behind, respins don't help with security bugfixes in a timely manner, so that point is moot and I get my distros for a coupla bucks snail mail anyway, so that isn't that important.

    Here is the link Presto

When you say 'old' it depends what you want to run on them.
As a developer I use a whole range of systems, and I don't throw old machines away, I use them for testing.

• My main desktop is a Quad core AMD Phenom with 8G of memory
• Sitting next to that are two AMD Athlon machines, each with 4G of memory

I also have

• Four Pentium III machines with 512M of memory
• Two AMD K6 machines with 256M of memory
• Four Pentium I (yes one) machines with 64M of memory

A Pentium III machine with 512M of memory is quite capable of running a fairly complex website. I use them to test websites developed using the Drupal content management system. If your website won't load and run in 512M of memory - you are probably doing something wrong.

In the past I have used Xen VMs, but at the time I found it tricky to setup (from what I have seen it has improved a lot since then, so this may be a better option now). For setting up a simple test system, it worked out easier to fire up one of the old machines and run the tests on that.
If I need to setup a test system that other members of our team can access, I use rented VMs from one of the cloud providers, FlexiScale, SliceHost or Amazon EC2.

One thing I would recommend is that you never configure a machine by hand. Everything should be automatic, using shell scripts or equivalent to setup the machines. Everything, including the scripts for installing packages and configuring the system should be in source control.

To setup a new set of tests, I start by writing a shell script that will install and configure all the components needed to run the tests. It will take a while to create the first few scripts, but you will gradually build up a library of functions that you can re-use. Someone else has already mentioned using Puppet and Cobbler to achieve the same thing. Unfortunately they weren't around when I started doing this. I haven't used either of them yet, but I hope to experiment with them fairly soon.

Whichever system you use, automating the install and configuration will save you a huge amount of time in the long run. Using my library of configuration scripts, I can setup and configure a new test system in a matter of minutes. The configuration scripts are designed to be portable, so I can use the same tools on one of my local test machines, or on an external VM hosted by a cloud provider.

As to what I use the Pentium I machines for - stress testing. I write Java web services for a UK eScience project, processing large (Tbyte) data sets. One of the things I need to check is the webservice should never try to load the entire dataset into memory. It should process the data bit at a time, and free up resources as soon as it has finished with them. As a stress test, I deploy a webservice on one of the tiny 64M machines, and then run multiple clients on the bigger more capable machines to hammer it into the ground, repeatedly, day after day for a week. If my webservice can process Gbyte data sets on a Pentium I machine that only has 64M of memory - without grinding to a halt. Then I can be fairly confident that when the same webservice is deployed on a multi core machine with Gbytes of memory it will probably be able to cope with the kind of load our scientists intend to throw at it.

Summary : Keep the old machines and learn how to setup, configure and use them as test machines. In the process you will encounter many of the problems that your developers and sys admins have to cope with on a daily basis, and you will be much better placed to be able t

From reading https://fedorahosted.org/spacewalk/wiki/SpacewalkFaq it sounds like they have plans on making it not so oracle-centric.

it's planned to tie in with freeIPA https://fedorahosted.org/spacewalk/wiki/TheRoadmap

Yes, it does make sense and that's why Fedoras live USB stick exists: https://fedorahosted.org/liveusb-creator

Linux users are way too paranoid to let any of their distros report back install data.

They're not as paranoid as you think. Hundreds of thousands of Fedora (and some other distro) users are allowing Smolt to collect their machine stats.