Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


FUSE Support OpenVZ - how common?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

FUSE Support OpenVZ - how common?

pubcrawlerpubcrawler Banned
edited November 2012 in General

Went through the big list of VPSes we have here - all the OpenVZ ones.

None of them have FUSE enabled by default.

For those on the provider side and those using FUSE based solutions, how common is it for provider to enable FUSE? Are there any providers folks can recommend that are FUSE-friendly?

«1

Comments

  • jhjh Member
    edited November 2012

    They should do it if you ask. If you don't want to waste time asking, just pick up something Xen/KVM based.

  • I think BuyVM has FUSE enabled by default? Otherwise, it's not difficult to do; any provider should be willing to do so.

  • Oh I'll waste the time :) Have some good sized storage plans on OpenVZ I'd like to keep and utilize :)

  • concerto49concerto49 Member
    edited November 2012

    We have FUSE enabled :)

    You'll need to put it in the order notes OR to support a ticket though.

  • Nick_ANick_A Member, Top Host, Host Rep

    We enabled it upon request. We promote that fact in our advertisements.

  • @concerto49, waiting for your storage offers :)

    Yep, BuyVM are sweethearts @Damian. They have FUSE enabled, perhaps by request.

    Rebooted, but still experiencing FUSE issues:

    libkmod: ERROR ../libkmod/libkmod.c:505 kmod_lookup_alias_from_builtin_file: could not open builtin file '/lib/modules/2.6.32-pony6-3/modules.builtin.bin'
    FATAL: Module fuse not found.

    Anyone know the intricacies of getting FUSE to work inside the OpenVZ container. This is just Debian 6, nothing strange.

  • concerto49concerto49 Member
    edited November 2012

    @pubcrawler said: Yep, BuyVM are sweethearts @Damian. They have FUSE enabled, perhaps by request.

    Yes, FUSE needs to be enabled manually on your VPS.

    @pubcrawler said: @concerto49, waiting for your storage offers :)

    Thanks. Still quite long until we can make another LET offer.

  • letboxletbox Member, Patron Provider

    Fuse can be enabled via our Control panel :)

  • Thanks @key12. Glad to see a provider putting what they support (like FUSE) in their offer posts. Hadn't seen your offers before.

  • joepie91joepie91 Member, Patron Provider

    @pubcrawler said: Are there any providers folks can recommend that are FUSE-friendly?

    RAM Host, afaik.

  • SpeedBusSpeedBus Member, Host Rep

    Open in a ticket and we'll enable it (CrownCloud) ;)

  • MaouniqueMaounique Host Rep, Veteran

    Prometeus also enables it on request. You need to open a ticket, though.
    M

  • jarjar Patron Provider, Top Host, Veteran
    edited November 2012

    I've never really considered enabling it by default on all containers, but certainly not opposed to the idea at first glance. Any clients of mine can currently request that it be enabled and I have no problem with turning it on.

  • What's FUSE required for, anyway?

    I know s3fs depends on FUSE. What else?

  • MaouniqueMaounique Host Rep, Veteran
    edited November 2012

    You need it to mount remote file systems.
    Normally, the kernel controls the filesystem, however, in OVZ containers dont have enough access to the kernel so a users-space FS is needed. FUSE means filesystem in userspace.
    M

  • @WhizzWr, FUSE is a filesystem tie in layer of sorts. Think of it as an API for the filesystem.

    SSHFS, which is SSH channeled filesystem requires it. Any distributed file system like Gluster requires it as they are built on top of FUSE.

    The lovely world of Linux and dependencies ;)

  • @Maounique said: You need it to mount remote file systems.

    Ah so that's it. Thanks

  • There are also crypto solutions like Truecrypt that require FUSE in order to work on the server itself. So in that case it is used for the local filesystem.

  • MaouniqueMaounique Host Rep, Veteran

    Yeah, since OVZ containers dont have a kernel to control the FS any other than the local system controlled by the host kernel require some user-space solution.
    Running truecrypt or other encryption system on a virtual machine you do not control defeats the purpose, IMO, since you try to hide the files from the admins and whoever controls the machine and can read the memory will be able to find the keys while the containers are mounted locally. But this is another story.
    If you have to host files remotely and encrypted, just share them with NFS, CIFS, even iSCSI if you feel like it and mount them locally and that does not require FUSE remotely.
    General need for the FUSE module is to mount remote FS, this is why ppl need it most of the time.
    M

  • Thanks @SpeedBus, will put a ticket in. Am a customer of your company too :)

  • You can run UML with your own kernel inside OpenVZ and then do whatever you want inside the UML. It would be ugly... but still possible :)

  • @Maounique, precisely.

    There are tons of FUSE based solutions. Truecrypt I mentioned since many folks know of it. Other FUSE things would be fore more vague and yawn inducing.

    In the tinkering stage now with distributed storage ideas across VPS'es. Been using rsync to date, but looking for something a tad different for some other uses. Resource pooling is where it is at, versus having idle nodes sitting around collecting dust.

  • @Maounique The belief you can trust the provider to maintain the privacy and confidentiality of your information is implicit when you use a hosting provider, whether encrypted or not. Guarding against others who might break into your VM or other users on the same VM is the real issue.

    So it raises the question, can hosting providers and/or their staff be trusted not to peek at customer files unless approved or requested the customer for a support issue? Do they act that way as a matter of company policy?

  • I'm kind of concerned about privacy with provider.

    I can't blame them for babysitting nodes. But, beyond some automated root kit hunters and similar, they don't belong in people's files.

    That's why in part what we do is centralize our data and files on real servers and only feed VPS'es limit sets of data. Mainly the static files on an as-needed basis and with routine purges.

    This concern though is real when dealing with storage VPS'es intended for backups. That can't be secure enough and involve enough trust.

  • @pubcrawler you should consider uploading only encrypted archives on those storage VPSes. Encrypted somewhere else that is, in a trusted environment.

  • MaouniqueMaounique Host Rep, Veteran

    @pubcrawler said: This concern though is real when dealing with storage VPS'es intended for backups.

    As I said, you can use them only as storage for the encrypted containers. Use some NFS or CIFS to export them and mount on your computer/server. The provider will never know the password, will see just encrypted blocks coming and going if will snoop around at traffic.
    On OVZ the provider is REQUIRED to watch processes and see which are abusing the node, then will see the offending container and take the necessary actions. Some use scripts to block some processes which are forbidden by ToS/AUP, check for hacking, etc. So, privacy is just a word if you do not take the necessary steps.
    M

  • I haven't truly combed over the security implications of the containers stored remotely.

    Obviously fine when just a file on there. Issue is when opened up to access and who has what. If we can facilitate that over SSH and do everything on the non storage node then should be relatively alright.

    Pretty accustomed to monkeying with SSH and living in tunnels :)

  • jarjar Patron Provider, Top Host, Veteran
    edited November 2012

    @Maounique I don't know about other providers but I know I'm not snooping through packets, the idea of it makes my head hurt alone ;)

  • I AM snooping through packets, when three is a DoS coming in. During the rest of the time - no, thanks :)

Sign In or Register to comment.