hurricanehrndz

Exact same thing i'm getting. Ha ha, the host i'm on is called DockerServer without the hyphen.

https://github.com/FreeRDP/FreeRDP-WebConnect/issues/81 Yeah I saw that, but I can't even clone the project. https://casablanca.codeplex.com/wikipage?title=Setup%20and%20Build%20on%20Linux&referringTitle=Documentation

Plus, it's not freerdp that is the problem, it is freerdp-webconnect. Specifically casablanca

this builds in phusion 0.9.16 lot of dependencies to build, but the compile only takes about 2 minutes tops. You built it within the machine? I was trying to avoid that in order to minimize the bloat of having to install gcc and things like that. I will give this a shot myself and report back. Take a 2 phase approach. Step 1, create a docker container just for compiling and creating packages. Step 2, install the created package into the pristine docker container. The docker in step 1 will not be published for end users to use. The docker in step 2 is what the end users will use. Yeah that's the approach I was trying to take.

this builds in phusion 0.9.16 lot of dependencies to build, but the compile only takes about 2 minutes tops. You built it within the machine? I was trying to avoid that in order to minimize the bloat of having to install gcc and things like that. I will give this a shot myself and report back.

It's not about building it into unraid, I think it would be better if we made it part of the container. Sort of like how novnc is part of my tmm container.

So I have tried FreeRDP, and it seems like it rather difficult to try get it compiled for recent distros. So I think I might be abandoning that idea.

Question on this, why don't you see a difference between 1 and 2? Do you think we should just make one image that includes the desktop gui anyway and if the app needs it, it's there? I guess I'm trying to understand what we should do for apps like Crashplan? Let the app maintainer add their own xvfb / vnc / rdp components? NM, I thought baseimage 2 was just a plain desktop that people could do anything with. I thought baseimage 1 was to webify desktop applications.

I'd like to have two base images created for the community to use or at least reference when building their own. We're not going to stop anyone who wants to align to a different base image (Phusion, Arch, etc.). We just want to provide an option to simplify things for container authors and for those that do want to use their own base image, at least provide a Dockerfile as a frame of reference for them. Base image 1: For Applications w/ Web Interfaces Base image 2: For Applications w/ Desktop Interfaces Base image 1 I think is pretty self-explanatory, but base image 2 could be made into a full virtual desktop where all user-created data is stored outside the image through volume mappings, but the OS and it's packages would be updated independently from the user installed components. That could be tricky and in the end, maybe not all that valuable. I'd rather keep each desktop application in it's own separate container and just connect to the application interface itself when I need it. I don't think we need a full Linux virtual desktop with persistent storage really. That would be a pretty niche use case. The benefit of keeping the OS and App layer's attached is to keep upgrades in alignment. Let's say an app update comes out but it relies upon upgrades to other packages in the base image. Now you're in a situation where your images are out of alignment and problems can ensue. If we think about Containers as a virtual image which marries an OS operating environment to a single application, we simplify supportability. I'm definitely interested to hear examples of where a fully persistent virtual desktop through Docker makes sense because if I'm missing something here, I want to know. So I'm interested to hear thoughts on this from everyone and let me know if you guys think I should post this in a new thread instead and I'll split the topic. Protocol has to be rdp, I think I found a noVNC like app for rdp. I'm in the process of updating my TMM to xrdp for demonstration purposes. I don't think base image 2 is necessary, but there will always be someone to argue. Base Image 1 makes perfect sense and keeps with the docker philosophy of docker base images being contained applications.

Would it be possible to develop a "vanilla" docker app for this, to allow for the end-user to install several apps on if they so desired, I use the current crash plan docker and agree that this would make an excellent alternative but wouldn't want to limit it's possibilities to just a series of single dockers. Maybe like an "easy-VM" although I understand that may be violating several if not all docker best practice guidelines... It'd be tricky cos as is at the moment, soon as the container is updated, you'll lose anything you install. Not necessarily, users could always use the docker commit command to make an image of the current running container from which they could then make more containers from. It wouldn't be easy to use, but it's definitely possible.

Yeah, I thought it was awesome when I first discovered it like 3 months ago. I always wanted a mediamanager that ran on unRAID, but unfortunately most where desktop apps. So when I discovered the framebuffer, novnc, and X11vnc. I was in heaven. If you have any question let me know, and I will be happy to assist.

Hey guys sorry drop in on your conversation here. I have successfully for awhile now, been able to turn desktop apps into webapps. Via VNC and novnc and using a frame buffer. My tinyMediaManager container is a perfect example of this. You can find https://github.com/HurricaneHernandez/tmm

This has been updated to latest beta release.

You can updated yourself, I was sure I had design it this way. Stop the container. Replace the jar file in the config directory with the new version and and ensure the permission are right.

I will update it shortly. Thanks for the post. If you wanted to do it manually docker exec would be the best, I will update the image though. unRAID best practice suggest all updating be done by developers and not the containers themselves.

Yes you can. Are you running the docker version or just the actual java install? If using docker with the new image https://registry.hub.docker.com/u/hurricane/tinymediamanager/ I would use docker exec -ti containername /scripts/tinyMediaManangerCMD.sh $PARMS replace containername with the name of your container and replace $PARMS with available options, please tinyMediaManager readme or forum for this info.

Ok

This is, mainly, due to philosophical differences with the "original" container developer, and some apps are more problematic than others. Needo's NZBGet and mine are different in the way I use pre-compiled deb packages to make possible in-app updates; his container relies on the official repository version and build routines to provide the "EDGE feature". So mine is seamlessly to the user, but I have the job to maintain it always updated with pre-compiled packages; in his case, the user must recreate the container with the correct EDGE variable set, but he has a lot less hassle maintaining it. The origin of the difference is that the package maintainer of NZBGet takes several months to push an update, so or we stay far behind using old buggy version, of we update it somehow. Bottom line is: there's a lot of ways to provide some dockerized app, and every method was it's advantages/disadvantages. It's natural to have more than one approach of offering an application, so it's normal to have more than one container per application. I agree with you. I don't agree with policing docker applications and telling developers what is best or not. Most people building these apps build them for themselves and then decide to share. Personally I don't agree with the fusion base image. I despise it actually, why is ssh included as part of the base image? SSH is no longer needed not with docker exec being available, sure I can agree at one point and time it was useful in order to debug containers, but that is no longer the case. Most images are on github so if people have an issue they can fork a project themselves and edit as they see fit.

You can updated yourself, I was sure I had design it this way. Stop the container. Replace the jar file in the config directory with the new version and and ensure the permission are right.

I will look at it today for you.

Ubooquity: Ubooquity is a free, lightweight and easy-to-use home server for your comics and ebooks. Use it to access your files from anywhere, with a tablet, an e-reader, a phone or a computer. gitub: https://github.com/HurricaneHernandez/ubooquity docker repo: https://registry.hub.docker.com/u/hurricane/ubooquity/ template: https://github.com/HurricaneHernandez/container-templates You can adjust the port Ubooquity runs on by providing the environment variable UBOOQUITY_PORT with which port you wish. The link in the template will obviously be broken though, so you might have to adjust it manually. Please visit once installed http://ip:8085/admin or if you used the template just click the image.

Perhaps once I start using circus I can achieve this. In terms of tmm, I really like. It seems to be doing really well. I use it in conjunction with MediaBrowser.

I will create a template shortly. I'm also updating the image from supervisor to circus, because I would like the boot process of the container to be more fail safe.

Your very welcome.

Official repo, is made by me and I build it in conjunction with the developers of mediabrowser. Once they let me know they are ready to build a new beta or new stable release I start my work. So the official repo is updated every time a release by mediabrowser is made. The base image is a big difference, but other than that I don't see much of a difference. If you want something that is updated regularly go with the official repo one, the official repo one runs by default as user nobody so it it compatible with unRAID. The readme instructions are a little outdate, and I will update them soon. Just remember that the config volume is /config