Hi all,
I was thinking today that for Fedora 23 it would really cool to deliver a NAS version of Fedora 23. I could see it being delivered in 2 formats.
1 an atomic based disk image. it could be preinstalled, you dd the image onto a disk or a usb stick plug it in and boot, you could use initial-setup to set a root password, set timezone etc, then use cockpit to manage and configure. my thought here is that you could use a mirco-atx system with 4 or 6 sata ports and you use all the disks for data and boot and run the system from a small piece of media, 16 or 32G usb stick for instance. or even a beaglebone black or similar arm based device with a attached usb disk
2 as a option you can select on a regular install.
The roles would be iscsi( or some other block device), nfs, smb/cifs. all managed and configured using cockpit, a user could carve up the attached disk, be able to alloacte nfs or smb/cifs or export some raw space as a block device, for use in vms etc.
I know it is a pretty rough outline but figured I would get something out and some discussion to see if what others thought. I think especially the atomic version could be really useful. a very simple way to get some storage up and running and use and keep it updated. especially long term, since going from Fedora 23 to 24 should be a simple atomic update.
Regards
Dennis
On Mon, May 25, 2015 at 06:44:49PM -0500, Dennis Gilmore wrote:
I know it is a pretty rough outline but figured I would get something out and some discussion to see if what others thought. I think especially the atomic version could be really useful. a very simple way to get some storage up and running and use and keep it updated. especially long term, since going from Fedora 23 to 24 should be a simple atomic update.
I like the idea, and I think it would make a lot of sense for a Fedora Server role.
I think it'd be nice to have a relatively simple interface where one sees storage as a pool of (redundant) disks, probably grouped into /srv or whatever, and then a separate interface for exporting directories from that volume via cifs, nfs, or others (but I think cifs and nfs as top priority).
I like the idea in general for using atomic/ostree here, but I wonder if maybe this would be best in the general context of making _all_ of the server roles available that way.
----- Original Message -----
On Mon, May 25, 2015 at 06:44:49PM -0500, Dennis Gilmore wrote:
I know it is a pretty rough outline but figured I would get something out and some discussion to see if what others thought. I think especially the atomic version could be really useful. a very simple way to get some storage up and running and use and keep it updated. especially long term, since going from Fedora 23 to 24 should be a simple atomic update.
I like the idea, and I think it would make a lot of sense for a Fedora Server role.
I think it'd be nice to have a relatively simple interface where one sees storage as a pool of (redundant) disks, probably grouped into /srv or whatever, and then a separate interface for exporting directories from that volume via cifs, nfs, or others (but I think cifs and nfs as top priority).
I like the idea in general for using atomic/ostree here, but I wonder if maybe this would be best in the general context of making _all_ of the server roles available that way.
For embedded devices like NAS I think Atomic based image is much more suitable than traditional Server installation. And just a pure image, roles sounds like container but why not to have same roles on top of both NAS and server? Maybe one day...
Jaroslav
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server
On 05/25/2015 06:44 PM, Dennis Gilmore wrote:
Hi all,
I was thinking today that for Fedora 23 it would really cool to deliver a NAS version of Fedora 23. I could see it being delivered in 2 formats.
1 an atomic based disk image. it could be preinstalled, you dd the image onto a disk or a usb stick plug it in and boot, you could use initial-setup to set a root password, set timezone etc, then use cockpit to manage and configure. my thought here is that you could use a mirco-atx system with 4 or 6 sata ports and you use all the disks for data and boot and run the system from a small piece of media, 16 or 32G usb stick for instance. or even a beaglebone black or similar arm based device with a attached usb disk
2 as a option you can select on a regular install.
The roles would be iscsi( or some other block device), nfs, smb/cifs. all managed and configured using cockpit, a user could carve up the attached disk, be able to alloacte nfs or smb/cifs or export some raw space as a block device, for use in vms etc.
I know it is a pretty rough outline but figured I would get something out and some discussion to see if what others thought. I think especially the atomic version could be really useful. a very simple way to get some storage up and running and use and keep it updated. especially long term, since going from Fedora 23 to 24 should be a simple atomic update.
Regards
Dennis
I'm actually running F21 in this way. I installed F21 to a 16GB USB thumb drive, and boot an Intel motherboard with 6 SATA ports from the drive. I've got 6 2TB drives in it, and used Cockpit to build the RAID on them. This is as far as Cockpit went, though - all other configuration was done the old fashioned way through the command line.
To make this as flexible as possible, I feel we still need a good WebUI for Samba, as well as NFS and iSCSI. FreeNAS has done an awesome job on their interface that provides all of these options, I wonder if we can use any of their code in Cockpit, at the very least for inspiration.
Regards, Dan
Dan Mossor danofsatx@gmail.com writes:
To make this as flexible as possible, I feel we still need a good WebUI for Samba, as well as NFS and iSCSI. FreeNAS has done an awesome job on their interface that provides all of these options, I wonder if we can use any of their code in Cockpit, at the very least for inspiration.
Interesting! Storage-wise Cockpit is moving from UDisks2 to storaged as the backend. Storaged is a fork of UDisks2 and is rapidly acquiring new features like iSCSI, LVM2, and support for libstoragemgmt. Network filesystems would be a good fit but I don't know whether anybody is working on that already.
On Tue, 26 May 2015 10:03:23 +0300 Marius Vollmer marius.vollmer@redhat.com wrote:
Dan Mossor danofsatx@gmail.com writes:
To make this as flexible as possible, I feel we still need a good WebUI for Samba, as well as NFS and iSCSI. FreeNAS has done an awesome job on their interface that provides all of these options, I wonder if we can use any of their code in Cockpit, at the very least for inspiration.
Interesting! Storage-wise Cockpit is moving from UDisks2 to storaged as the backend. Storaged is a fork of UDisks2 and is rapidly acquiring new features like iSCSI, LVM2, and support for libstoragemgmt. Network filesystems would be a good fit but I don't know whether anybody is working on that already.
Hi. I'm pretty sure nobody works on anything Samba or NFS related in storaged. And we can only configure the iSCSI initiator which is not that interesting for the NAS use-case. Speaking of the proposed idea (NAS configuration UI). I wonder if that would really be a good fit for the storaged API. So far we were dealing with the storage devices, filesystems, etc. This would broaden the scope to a storage services management too. We have not really considered that (yet...).
I can imagine that Samba configuration management would be quite demanded feature. However Samba is much more than just a file sharing service and I'm not sure we would be able to simply isolate that one piece from it. So we may need special APIs for Samba for example. NFS server and iSCSI target might be simpler but again: it's more services configuration than storage.
Regards,
On Tue, 2015-05-26 at 10:44 +0200, Tomáš Smetana wrote:
On Tue, 26 May 2015 10:03:23 +0300 Marius Vollmer marius.vollmer@redhat.com wrote:
Dan Mossor danofsatx@gmail.com writes:
To make this as flexible as possible, I feel we still need a good WebUI for Samba, as well as NFS and iSCSI. FreeNAS has done an awesome job on their interface that provides all of these options, I wonder if we can use any of their code in Cockpit, at the very least for inspiration.
Interesting! Storage-wise Cockpit is moving from UDisks2 to storaged as the backend. Storaged is a fork of UDisks2 and is rapidly acquiring new features like iSCSI, LVM2, and support for libstoragemgmt. Network filesystems would be a good fit but I don't know whether anybody is working on that already.
Hi. I'm pretty sure nobody works on anything Samba or NFS related in storaged. And we can only configure the iSCSI initiator which is not that interesting for the NAS use-case. Speaking of the proposed idea (NAS configuration UI). I wonder if that would really be a good fit for the storaged API. So far we were dealing with the storage devices, filesystems, etc. This would broaden the scope to a storage services management too. We have not really considered that (yet...).
I think the umbrella of the storaged project would be a good place to build up these APIs, if only to be able to capitalize on the wide domain knowledge of the other developers on that project.
I can imagine that Samba configuration management would be quite demanded feature. However Samba is much more than just a file sharing service and I'm not sure we would be able to simply isolate that one piece from it. So we may need special APIs for Samba for example.
We certainly do need to write an API to manage SMB, but I think it's a lot simpler to do than one might think. We don't necessarily need to isolate everything, we just need to modify the smb.conf file and reload the daemon.
NFS server and iSCSI target might be simpler but again: it's more services configuration than storage.
Sure, but given all the success you've managed in converging into a single set of APIs, it seems counterproductive to attempt to build this elsewhere, to me.
On Tue, May 26, 2015 at 10:44:50AM +0200, Tomáš Smetana wrote:
I'm pretty sure nobody works on anything Samba or NFS related in storaged.
To me, it seems like "inside the box" storage configation and "export methods and permissions" are conceptually separate. I think for the NAS idea, this could be fairly opinionated (allowing us, among other things, to get SELinux right). One half would be "Configure storage however you want to get a volume mounted at /srv/fedora-nas" (Or whatever we select), and the other half would be "export subdirectories of /srv/fedora-nas via your choice of tech".
demanded feature. However Samba is much more than just a file sharing service and I'm not sure we would be able to simply isolate that one piece from it. So we may need special APIs for Samba for example. NFS server and iSCSI target might be simpler but again: it's more services configuration than storage.
I think we _should_ isolate just that point. Samba installed for the Fedora Server NAS role should _only_ do that. You want some other functionality or configuration, run a different Samba.
On Tue, 26 May 2015 10:03:23 +0300 Marius Vollmer marius.vollmer@redhat.com wrote:
Dan Mossor danofsatx@gmail.com writes:
To make this as flexible as possible, I feel we still need a good WebUI for Samba, as well as NFS and iSCSI. FreeNAS has done an awesome job on their interface that provides all of these options, I wonder if we can use any of their code in Cockpit, at the very least for inspiration.
Interesting! Storage-wise Cockpit is moving from UDisks2 to storaged as the backend. Storaged is a fork of UDisks2 and is rapidly acquiring new features like iSCSI, LVM2, and support for libstoragemgmt. Network filesystems would be a good fit but I don't know whether anybody is working on that already.
Just for the completeness: yesterday I have learnt about the targetd project that lets "a remote administrator allocate volumes from an LVM volume group, and export those volumes over iSCSI. It also has the ability to create remote file systems and export those file systems via NFS/CIFS (work in progress)":
https://github.com/agrover/targetd
That sounds a lot like the functionality we're talking about. And targetd is packaged in Fedora already.
Regards,
----- Original Message -----
Hi all,
I was thinking today that for Fedora 23 it would really cool to deliver a NAS version of Fedora 23. I could see it being delivered in 2 formats.
1 an atomic based disk image. it could be preinstalled, you dd the image onto a disk or a usb stick plug it in and boot, you could use initial-setup to set a root password, set timezone etc, then use cockpit to manage and configure. my thought here is that you could use a mirco-atx system with 4 or 6 sata ports and you use all the disks for data and boot and run the system from a small piece of media, 16 or 32G usb stick for instance. or even a beaglebone black or similar arm based device with a attached usb disk
Excellent idea, I've just read a discussion about NAS on one Czech Linux web, people looking for SW, or even small ARM based HW with enough SATA ports, enclosure for two disks and fast Ethernet. There are commercially available NAS devices, I'm looking for such but after reading how you have to hack it to work as you want and the price...
What's the best ARM board you think? With SATA and fast Ethernet? Maybe some case would be easy to design and then kickstart it (with Fedora NAS pre- installed ;-).
2 as a option you can select on a regular install.
The roles would be iscsi( or some other block device), nfs, smb/cifs. all managed and configured using cockpit, a user could carve up the attached disk, be able to alloacte nfs or smb/cifs or export some raw space as a block device, for use in vms etc.
One more role to consider - ownCloud. And maybe backup server with client integrated into Fedora.
I know it is a pretty rough outline but figured I would get something out and some discussion to see if what others thought. I think especially the atomic version could be really useful. a very simple way to get some storage up and running and use and keep it updated. especially long term, since going from Fedora 23 to 24 should be a simple atomic update.
Thanks for idea, I like it! Or maybe I'm just desperate after looking for something like this last three weeks with no answer. In the end, I just paid €99 for DropBox - well integrated to all platforms I use (I know, slightly different usecase but that's why I'd like to see ownCloud there - it will work as my personal cloud remotely, locally as NAS and backup). Many of these boxes can sync with cloud services (I tried my router's NAS features).
Jaroslav
Regards
Dennis
server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server
On Tue, 2015-05-26 at 05:08 -0400, Jaroslav Reznik wrote:
One more role to consider - ownCloud. And maybe backup server with client integrated into Fedora.
ownCloud has certainly been on my radar and I've been hoping that Adam Williamson (who has been maintaining it in Fedora) would be interested in helping to put together a server role definition for it.
----- Original Message -----
From: "Stephen Gallagher" sgallagh@redhat.com To: server@lists.fedoraproject.org Sent: Tuesday, May 26, 2015 9:04:27 PM Subject: Re: RFC Fedora 23 Change idea
On Tue, 2015-05-26 at 05:08 -0400, Jaroslav Reznik wrote:
One more role to consider - ownCloud. And maybe backup server with client integrated into Fedora.
ownCloud has certainly been on my radar and I've been hoping that Adam Williamson (who has been maintaining it in Fedora) would be interested in helping to put together a server role definition for it.
Nice to see more people sharing interests with ownCloud. I would like to help out a hand too. Count me in.
Rgds, Tuan
On Mon, 2015-05-25 at 18:44 -0500, Dennis Gilmore wrote:
Hi all,
I was thinking today that for Fedora 23 it would really cool to deliver a NAS version of Fedora 23. I could see it being delivered in 2 formats.
1 an atomic based disk image. it could be preinstalled, you dd the image onto a disk or a usb stick plug it in and boot, you could use initial -setup to set a root password, set timezone etc, then use cockpit to manage and configure. my thought here is that you could use a mirco-atx system with 4 or 6 sata ports and you use all the disks for data and boot and run the system from a small piece of media, 16 or 32G usb stick for instance. or even a beaglebone black or similar arm based device with a attached usb disk
2 as a option you can select on a regular install.
The roles would be iscsi( or some other block device), nfs, smb/cifs. all managed and configured using cockpit, a user could carve up the attached disk, be able to alloacte nfs or smb/cifs or export some raw space as a block device, for use in vms etc.
I know it is a pretty rough outline but figured I would get something out and some discussion to see if what others thought. I think especially the atomic version could be really useful. a very simple way to get some storage up and running and use and keep it updated. especially long term, since going from Fedora 23 to 24 should be a simple atomic update.
The atomic-based one is an interesting idea, but it's a pretty crowded space. For example, I've got a Synology D214 at home that is basically this exact idea in a relatively cheap (and low-power) case. It's even built atop Linux and open-source[1] (though the UI is not).
So I'm not sure it's necessarily a good use of our effort to move into a space that already has a strong player (at least for F23). I do however think that there is a lot to be gained by building up a powerful user experience for doing file-sharing in Fedora Server. I'm not sure we want to tackle all of the possibilities at once though; it might be prudent to hit at most one or two of the most valuable ones first. In my mind, that would be SMB and/or NFS for the first pass. (And unless we have a lot of people excited about working on it, we should really pick just one; probably SMB).
One thing we can and should do with Fedora Server is tie the access -control and authorization decisions in with our domain controller role. I think we can make it possible to set up simple username/password-based shares, but managing authorization decisions using FreeIPA HBAC (and possibly AD GPO down the road, but not for the first pass) would be very valuable.
If we choose to work on NFS, we should set up a simple mechanism to accommodate two popular uses: * Kerberized NFSv4 working with the domain controller * NFS home-directories
If we choose to work on SMB, we need to make sure that we can interoperate cleanly with Active Directory domains as well as FreeIPA -Active Directory cross-realm trusts.
So let's discuss this at length during the meeting today.
[1] http://sourceforge.net/projects/dsgpl/files/?source=navbar
----- Original Message -----
On Mon, 2015-05-25 at 18:44 -0500, Dennis Gilmore wrote:
Hi all,
I was thinking today that for Fedora 23 it would really cool to deliver a NAS version of Fedora 23. I could see it being delivered in 2 formats.
1 an atomic based disk image. it could be preinstalled, you dd the image onto a disk or a usb stick plug it in and boot, you could use initial -setup to set a root password, set timezone etc, then use cockpit to manage and configure. my thought here is that you could use a mirco-atx system with 4 or 6 sata ports and you use all the disks for data and boot and run the system from a small piece of media, 16 or 32G usb stick for instance. or even a beaglebone black or similar arm based device with a attached usb disk
2 as a option you can select on a regular install.
The roles would be iscsi( or some other block device), nfs, smb/cifs. all managed and configured using cockpit, a user could carve up the attached disk, be able to alloacte nfs or smb/cifs or export some raw space as a block device, for use in vms etc.
I know it is a pretty rough outline but figured I would get something out and some discussion to see if what others thought. I think especially the atomic version could be really useful. a very simple way to get some storage up and running and use and keep it updated. especially long term, since going from Fedora 23 to 24 should be a simple atomic update.
The atomic-based one is an interesting idea, but it's a pretty crowded space. For example, I've got a Synology D214 at home that is basically this exact idea in a relatively cheap (and low-power) case. It's even built atop Linux and open-source[1] (though the UI is not).
Yes, it is an option but I'd not call it that cheap - I'm actually interested in and I was considering bying it. But then I started to Google it and I was pretty disappointed, that it is standard proprietary vendor lock-in thing although it's hackable at least...
Jaroslav
On 2015-05-26 01:44, Dennis Gilmore wrote:
2 as a option you can select on a regular install.
The roles would be iscsi( or some other block device), nfs, smb/cifs. all managed and configured using cockpit, a user could carve up the attached disk, be able to alloacte nfs or smb/cifs or export some raw space as a block device, for use in vms etc.
Making setting up a Samba server, NFS server or a ISCSI server (target) easier would be awesome. I think it would be good to start with SMB/NFS/ISCSI client configuration in Cockpit though. To walk before running so to say. For ISCSI client (initiator), there is a spec and some mockups, but no code yet. [1] Nothing for NFS yet, but it would be cool to tackle soon.
As I mentioned in the IRC meeting. If someone is really eager implement the code for the server parts first, I'm happy to help with the design.
1. https://github.com/cockpit-project/cockpit/wiki/Feature:-iSCSI-Initiator
- Andreas
server@lists.fedoraproject.org
-
Andreas Nilsson -
Dan Mossor -
Dennis Gilmore -
Jaroslav Reznik -
Marius Vollmer -
Matthew Miller -
Stephen Gallagher -
Tomáš Smetana -
Truong Anh Tuan