Where is fedora server

I will make them my PDF out of these for myself only these, as reference for near future. You are welcome. Share the link, promote Fedora Magazine and just implement similar solutions. It seems to work for me without it. Maybe it depends if you are using X11 or Wayland? Does it work for you with the following? They are not used by default for security reasons. Whether things work or not depends on whether specific environment variables are required in your specific case. You can configure them in the sudoer file too.

And it also has the advantage that if one drive dies I dont lose everything. Jim, but then you are limited to the max capacity of mounted physical drive.

It is also accepted solution and very popular for software applications and some software flexible solutions. Thank you for your comment — I like to see other options. I just wondered why you use so many physical drives. I wonder if it would make sense to buy one large hard drive and copy each of your legacy hard drives into a different partition. It would have saved you from having to buy more power and you would not have to deal with a panoply of aging hard drives.

Hi Frank, Decision depends on reader, how they would like to manage disk s. I thought it will be interesting to check how so many connected disks are performing. Of course we can build and test it on virtual disks but it is not the same as physical disks.

So this is a kind of overview, what can people expect when they would like to build — similar storage server. It is surprising for me, but proved by numbers. At the beginning I thought that rather it will be between a little over the half of the speed — between slowest and fastest drive. By using the same logic — by connecting together bigger, newer and exactly the same type of drives we can also expect better performance than single drive.

Must be proved in practice by somebody who has the same type of the drives. As I stated it is not fault tolerant solution. Without hardware acceleration any parity solution raid5, raid6 will be slower and will have impact on system performance processor. Of course important is to have DB tuned to one or multiple 64 KiB as stripe size is set. This is quite different topic. And for the end last remark. Because the priority was to have at least 2 copy of data in local network connected by 1 Gbps links, I always had decided to use: the same type of disks with RAID5 on ZFS but it was 10 years ago ;-.

Huge cost of professional storage disk forced me to find the storage solution which will be cheap and ready to use for my duties to give me some protection about data and space between 8TB and 12 TB at that time the largest affordable disks were 1 TB. By using Fedora people can learn how to do similar things at small scale. But first step is always to understand architecture of the solution, limitations, performance and physical implementation. This is why I share it.

Notify me of follow-up comments by email. Notify me of new posts by email. This site uses Akismet to reduce spam. Learn how your comment data is processed. Fedora Linux 35 is available now.

Read the release announcement for all the details. Email Address. The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site.

The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions. Prolog I came up with the idea to build a Linux-based storage server when I wanted to access some old photographs that were archived on various hard drives of differing makes, models, sizes, interface types and ages. I decided that my storage server would go through the following stages over time: Build a storage server from a desktop computer using magnetic disks.

Periodically make a backup of the storage server to one big offline drive. When the storage server reaches maximum capacity, I will reuse the offline drive as the internal drive. A new, bigger offline drive will be used in the same way as the old offline drive.

Fundamentally, I wanted to: organize my data into one easily-accessible place. In the former case, one does not need to worry about a RAID system. These instructions and notes primarily concern a bare metal installation. A "bare metal installation" is one where the Operating System Fedora Server Edition in this case is installed directly on the computer vs a virtual machine, in the cloud, etc.

Fedora Server comes with its own special installation ISO image, either as a full local installation or as a network installation. If at all possible, use one of the two Fedora Server Edition alternatives "Standard" or "Netinstall" and avoid booting from another image. Anaconda, the installation program and the GUI look alike for any edition or spin, but are tailored differently under the surface, e. If you ask 3 system administrators about the best practice for hard disk partitioning, you will get at least 5 different answers.

There is no clear, best way to partition your disks. While this subject is beyond the scope of this document, we can offer that we can expect 4g for a typical install. Talk to your friends, read up on the subject, search for articles, and make your own judgment. Many solutions are editable after installation but not all! The remaining area is filled with another partition and one volume group VG created therein. A logical volume of approximately 15 GB the exact value depends on the disk capacity of your system is created for the operating system and its software.

The other available space remains free for the creation of Logical Volumes LVs for user data, which are to be mounted at the appropriate positions in the directory tree of the system area. The rationale behind this is a separation of system and user data, which eases system administration, increases security, and decreases the likelihood of errors.

The system area i. System maintenance must not jeopardize user data under any circumstances. If necessary, it must be possible to unmount user data. If you are a more experienced administrator, you may wish further the rationale above with increased separation. A good size for this VG eg. Create a LV e. The remaining free space is left for distribution as needed over time. The remaining area of the hard disk is filled by a large partition and a VG for user data e.

It depends on your particular needs. They can develop for Vendor Y Release X and know that this platform will be around for several years to come. I thought I didn't have anything to add to this, but after having run Fedora in production for nearly two years - for my very important Zabbix monitoring system! First, it was not my first choice. However, for this particular deployment I absolutely required features in Zabbix 2. EPEL now has Zabbix 2.

If it had, I would never have tried this. So the tradeoff here is: Fedora has the latest software, but its releases are on a very short month lifecycle, with new releases made about every six months. This means I had to plan for a maintenance window to upgrade Fedora twice a year, in addition to the usual periodic installation of updates. For a monitoring system which is supposed to be keeping track of everything else , it's vital that such maintenance periods be as infrequent and as short as possible.

With the requirement to upgrade so frequently, this would usually rule out such a distribution, but remember that I had more pressing concerns; it would be useless without the features I needed.

So this is a tradeoff I made with nearly full knowledge of the consequences. Not long ago, I did the Fedora upgrade on this server, using Fedora's new fedup upgrade tool. I planned for a two-hour outage, with another two hours to possibly deal with any of the monitored services that might have died and that fact missed since Zabbix was down. The actual service downtime was 11 minutes. That's from the time Zabbix stopped before reboot to the time it was back up and monitoring services after the completed upgrade.

I did not realize that the downtime would be so short! I was expecting much more trouble , even though I know from experience that significant upgrade problems are uncommon with Fedora. And it's been improved further: When I did the Fedora upgrade, the complete downtime was an amazing six minutes.

The same time for This service will almost certainly be moved onto RHEL 7 when it becomes available. After this experience I'm much more confident in Fedora as a server and now intend to keep it, even with a major upgrade every six months.

Moving off to RHEL would be much more disruptive, and might limit me in the future, because of the following:. It's unfortunate that Red Hat has such a long time between major releases; a similar delay between EL5 and EL6 led me to actually put an Ubuntu installation into production, something I am still kicking myself over to this day.

For that system, I considered Fedora, but strangely it did not have the software I needed packaged at all at the time, despite an older version being in EPEL. One "problem" no one mentioned about running Fedora is that you will see many new things, both large software projects and tiny enhancements, well in advance of their inclusion in RHEL.

For example, Fedora has a large number of bash completions which aren't yet in RHEL by default; one notable one is tab completion for package names in the yum command line. So, it's certainly possible to use Fedora in production, so long as you can accept the tradeoffs:. All things considered, Fedora is still not my first choice for a server platform, and probably never will be.

Though I've been a happy Fedora desktop user for its entire existence. In the case where you absolutely need more current versions of software not available in a more "enterprisey" distribution, and you can accept the tradeoffs, then there is nothing wrong with using Fedora. As previously noted, there's no real difference in the pace of security updates between Fedora and any other distribution. Fedora packagers make special efforts to stay close to upstream and get these sorts of updates out as quickly as possible, sometimes even before the upstream project does.

Like its enterprisey big brother, Fedora also ships with a fairly locked down security configuration: services except ssh ship off by default; the default-deny firewall is enabled by default for both IPv4 and IPv6; SELinux is enforcing by default. In addition, Fedora is hardened in a number of other ways.

On the other hand, you get to see new security technology very early; one example is the recent introduction of FirewallD , which still isn't quite ready for prime time, though switching back to the previous firewall is easy. It's more about stability and rate of change than security, per se. Fedora is a platform for Red Hat to roll out new features and applications to validate their relevance, provide a platform to experiment, and work out integration issues.

That is usually not what you want a server to do -- you generally want a server to perform a function in the most stable way possible.

Depending on what you are doing, Fedora may be just fine. If you're developing Linux desktop apps, working with the bleeding edge may be desirable. Likewise, if you're working on a semester-long school project or some other limited duration project where the high tempo of changes isn't a concern, Fedora is fine as well. The key point that keeps me from using Fedora for a server and preferring Debian, Ubuntu or CentOS instead is the stability and length of support.

When you're running a server you want stability, security and longevity. Yes, almost every distro is packaging the same software so it doesn't matter there. It's a matter of what is tested, has security updates and is supported. Fedora's release schedule of every 6 months is nice if you want bleeding edge but when talking about a server bleeding edge is not always a good thing. Add on top of that the fact Fedora only supports the last three versions that means you're looking at an unsupported OS in 18 months and having to upgrade.

CentOS by far has the longest support cycle and during that time it is supported and security patches and updates are released so it's not the same release the entire time. The advantage of this is that you're not spending all your time preparing for the next upgrade.

You have a stable server with stable tested software running on it. Debian has a release schedule that is longer than Fedora but shorter then CentOS but is always up on security updates. The other advantage of Debian is a clean upgrade path. Debian releases are tested for both clean install and live upgrades and not actually released until it is able to be done successfully without problems.

This attention to detail and willingness to push back a release date to clear more package bugs is one of it's strongest pros. The DEB package structure itself is also engineered to make upgrading very smooth and maintain your configurations. The only thing it's lacking really is commerical support, in which case you can look to Ubuntu which takes it's packages from Debian just like CentOS takes much of it's packaging from RHEL.

Edit: Added bold text to draw attention to fact that was obviously missed that I do not consider Fedora stable enough for a server platform. Fedora does not have tech support contracts like Red Hat enterprise. There is no one to call if you have a show-stopping issue. Likewise, I would not recommend using Ubuntu for a server environment, and many would disagree with me, but that's simply not the primary target. Software that is targeted at home users and desktops tends to be lacking in the departments that are server-oriented, just like things that are targeted at the server don't work as well for home users.

Additionally, platforms targeted at home users tend to attract more home users, thus, the bugs that are discovered, reported, and fixed, will be prioritized due to that effect. Likewise, platforms targeted at server use will tend to attract server use, and thus bugs related to server use will be more likely to have been found and solved by the time you get to them.

I have at least one friend who has professional experience with Ubuntu in production environments and says he was entirely horrified by it, and would much prefer CentOS for production servers because.

From the NSA's own seLinux website :. Security-enhanced Linux is only intended to demonstrate mandatory controls in a modern operating system like Linux and thus is very unlikely by itself to meet any interesting definition of secure system.

Fedora aims to be closer to the 'bleeding edge'. This means you will get newer software that has spent less time being tested. It's my impression that because of this there are more updates on fedora , but again I don't have any numbers to back this up. What really swings it though it the lack of the LTS model that ubuntu has. You can install an ubuntu LTS a few months after it's been released and know that it's had plenty of time to sort out any major issues and settle down somewhat. After that you know you have a minimum 4 years of further support and upgrades before you have to upgrade your server.

I could live with any of the other potential issues with running fefora, but not with having to move release on each box a minimum of once per year probably twice though. Fedora 11 comes with openssh server version 5. When it's released ubuntu karmic will only have version 5. The centos website is too crap for me to be able to find a version, but afaik they're on 4. It's not that fedora is insecure. It's that it ships with bleeding edge packages, and that it refreshes very quickly, so you have to go through upgrades every year or so to keep getting security updates.

That's a big deal if you've got any non-trivial number of servers, especially given that the fedora update process iirc requires downtime. The main complaint you will find from server admins about Fedora on the server is the upgrade cycle every 6 months to a year depending on whether you always want to be on the latest or skip every other release. As you pointed out, Fedora installs "secure by default" configurations and provides a lot of tools for maintaining a secure system.

Especially on a server, the preupgrade tool will handle migrations between different Fedora releases just fine which mitigates that concern somewhat. If you want a longer release cycle, then something like CentOS which is essentially the free version of Red Hat Enterprise Linux may be easier on your workload.

To summarize, I think you're just fine with Fedora if you're happy with it. Any operating system can be made secure. Two points about Fedora as a server. One, every time you upgrade a software version you are running the risk of introducing new bugs and security problems not present in the prior version. This is why companies will want to wait a year after software comes out before installing it, so a lot of the bugs and security issues can be fixed.

You don't want to switch to new versions every time one comes out do to the migration headaches and new security issues involved. Second Fedora doesn't have the ability to get corporate support like RedHat or Ubuntu.

We use RHEL at work. If you had to upgrade 7k servers every 6 or 12 months, we'd never be ahead. We are still getting Win2k3 servers to Fedora releases are too frequent for a company with a lot of servers to stay current. For a small business, sure Fedora is probably okay to use. But then again, you would need a linux admin on site and most can't afford one to troubleshoot a lot of issues. So that's where RHEL has an advantage - paid support.

I used Debian at home. I just upgraded from 7 to 8 and it went very smooth. Ubuntu has a server too, but Ubuntu is equivalent to Fedora.

Debian takes a long time to roll out new packages because they test them thoroughly. The downside is, you may not have the latest Apache or MySQL or whatever application you need that has the features you want.

Sure you can download it separately, but it defeats the purpose of having a "stable and secure" OS. It's about comfort levels.