L0rdRaiden
-
Posts
568 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by L0rdRaiden
-
-
Sorry to rescue this old thread.
I was about to purchase this melanox model but seen that is not fully compatible is a problem.
Is there any other 40G card or better that is fully compatible with unraid and can be purchased used with a good price?
I have found the intel XL710-QDA1 but it cost almost 3 times more in ebay
-
Could you add an option to select several docker compose stacks to execute de actions Start / Stop / Update. Executing each stack in parallel if it's possible or in series.
I have quite a few right now and going 1 by 1 waiting for each to go with the next one is... slow.
-
What should I use in my applications? is there any difference or advange? performance? security? features?
/mnt/data/Video (ZFS way)
or
/mnt/user/Video (unraid way)
-
Why do you recommend to use eth0 instead of vhost0?
I'm planning to build this, the only change is that the docker0,1,2 will actually be lxc containers with docker inside.
Each lxc would have 2 interfaces assigned, one for administration of the lxc OS and another one for docker.
Ideally I would like to use macvlan in docker in order to have different IP's per container, but not sure yet how this will play over LXC. Maybe doing a bypass of the virtual nics inside lxc with facilitate everything.
Or maybe instead using different bridges to split the traffic I could creat vlans in eth0/vhost0 and assign 2 of the to each lxc and use macvlan on top of that for lxc and the docker inside lxc
I don't have yet a clear picture of the approach so unless I get some help I guess I will get it via the trial and error approach
I might find other problems with the storage at some point
-
Anyone is having problems using macvlan in lxc over linux bridges?
In unraid mixing docker macvlan with linux bridges causes "call traces" will the same happen with lxc?
I know there is a workaround but I'm still interested in using bridges and not just phisical nic + macvlan
-
I saw you have openned a bug in relation of the call traces when using macvlan over linux bridges, on linux kernel.
I know that linux packages are linux packages but not all the kernels are compiled with the same options.
On Google I don't see anyone having this issues that is not related with unraid, have you tried to reproduce this on debian 12 or rhel 8, 9 or any other distro?
https://bugzilla.kernel.org/show_bug.cgi?id=217777
Maybe this? https://bugzilla.redhat.com/show_bug.cgi?id=1091779
-
7 minutes ago, DivideBy0 said:
LOL, keep talking, keep digging, and get a troll mirror and take a look at it.
Since you din't get the hint the nice way, let me try another way. Your rubbish is just bunch of rambling non-sense and please stop polluting everyones time and availability.
MOVE ON mate, please. Get TrueNAS, get BSDI or SCO or Solaris for what I care, get even KALI on a CD if it makes you happy.
You are embarrassing yourself kid.
It must be hard being wrong for several posts and recognize it so you make the ball bigger.
Everyone else in the thread is wrong and you are right xD.
What is your problem with the statement that Unraid does not updates cve as quickly as other distros? Is a reality, why do you get mad?
Everything else about unraid being vulnerable now is only on your poor head.
I think you actually have real mental issues so I will stop responding you here. Good luck
-
8 minutes ago, DivideBy0 said:
Sorry mate but you're a child. I will be scared to hire you in this filed even as an intern. That being said I disengage from your nonsense ranting. I politely asked, show me the money and you kept on ranting. Unless you have objective proof take the backseat and you may learn something.
Poor kid, now you get mad?
Where I said that UNRAID is vulnerable?
I said that it follow an insecure vulnerability management policy.
Learn the difference and grow up.
Your problem is a lack of basic understanding in security and therfore you are mixing things up.
Everyone's else understood my stament and some people even agree with me.
So please move on and go to troll to another forum
-
8 minutes ago, Kilrah said:
If there's a vuln in these apps they get access to their container and that's it. It would take a docker vuln to escape that, and you can be sure if there was one Unraid would get patched for that
No, they're saying that Unraid itself (GUI, SSH, FTP, SMB...) should not. Nothing to do with the containerized services.
That could be a little bit optimistic. Lets assume the normal setup of an average user. Lets use a pentester mindset.
Once you breach a container basically you have access to the whole network so I don't need to break docker to reach the host.
Once in the network I might have access to
- Unraid GUI, SSH, FTP, SMB (remember when the default config of samba in unraid wan't secure a coupe of years ago? not because a CVE but due to config)
- Other container services
- Other physical devices in the network
- Other VM's
- Etc.
There are too many posibilities and some of them can be prevented having a OS properly maintained.
The other problem is that there are ton of people that doesn't upgrade unraid because they are afraid of breaking things (which happens a lot)... this is why regular OS have LTS versions with security patches at least guaranted.
-
5 minutes ago, MAM59 said:
Hey folks, calm down.
I am sure, you all have your different views of "security". From "I dont care about it" to "my server is my castle".
We all are aware that UNRAID does not focus on security. If you want this, move to NetBSD or something (all Linux is crap when it comes to security and networking).
But if you can live with the risk, all ist fine.
And about "CVEs fixed fast", I get three CVE warnings for two weeks now already from my FreeBSD box. No patch yet.
Should I be concerned? Yeah!
Should I panic? NO!
Should I kick their lazy ~!@? NO (they would correctly tell me, I should fix them myself or wait until they have time for it. At least they are already aware of them)
So, make peace with UNRAID, if you feel too unsafe, move on.
well you can panic depending on how the CVEs can be exploited and where in your network is the FreeBSD.
Still the fact is that Unraid doesn't care at all about CVEs and that could be quite bad, maybe not too bad for people who knows how to harden their environments but for noobs, since Unraid is aiming mainly for this kind of customers.
I understand that doing this in slackware for them can be a lot of work but is a irresponsability from their side promote the use of unraid to install things like plex, home assistant, jellyfin immich, netxcloud, and you would want those probably publised to internet and don't care about the basics of keeping unraid patched. What happens if there is a vulnerability in any of these apps? with docker and the SO unpached... is a recepy for a disaster at some point.
I mean how many post do you see here and in reddit of people asking for help to publish someting hosted in unraid and they don't even know how to open the ports of their routers, or what are the implications of that.
-
7 hours ago, DivideBy0 said:
But of course you had a rebuttal
So that leaves my UnRaid vulnerable / flying blind at SSL mercy. Enlighten me now what's the worse can and will happen with my UnRaid over SSL. Keep the facts objective, quantitative and not what you read or what you heard I have no need to hear what could potentially happen. Hard facts strictly related to UnRaid which you claim is unsecure but have no data or evidence to offer.
By the way Nessus will use the same scanning engines / plugins as the nmap ones, which really tells me how well versed you're in the world of cybersecurity if you don't know the difference.
And I don't believe you're grasping the concept of defense in depth. What the hell is "vulnerability and hardening in the host is also defense in depth."
I don't understand your arrogance, but you will learn something today
That is the problem, now one cares about your setup and no one is talking about your particular use case, if you don't have services hosted in Unraid exposed to internet of course reaching unraid will require the compromise of another asset in your network. But the problem is that there is many people exposing services hosted in Unraid to internet, and we have no assurance that the host is properly hardened and Unraid as a "company" is doing a propper vulnerability management, probably not because they never release patches with security updates, the release Unraid updates whenever they can and it comes with the patches of the last months, that means that Unraid has CVE for months not being patched.
So the evidence is clear and is a fact that vulnerability management is not done by Unraid, they don't release security updates out of the regular updates. Crystal clear.
Regading hardening, (configuration management), I doubt they are doing it, looking at the changes in the past but I don't have the proof, I havent scanned Unraid agasint DISA stig or CIS or any other hardeninig guide. Don't worry I will explaint you what is hardening in a second.
I have used Nmap and Nessus and qualys among others professionally for years, maybe is my fault because I was assuming that you have a basic knowledge about security and I didn't extend a lot my explanation. I was trying to be kind and explain in case you or others didn't know that for free you have a better option than nmap to scan the vulnerabilities in your environment, not only a unauthenticated network scan that is what nmap does. I know perfectly what Nessus is capable and its plugins Plugins | Tenable® not only for vulnerability management but for hardening.
QuoteAnd I don't believe you're grasping the concept of defense in depth. What the hell is "vulnerability and hardening in the host is also defense in depth."
Arrogance and ignorance are bad partners. So you talk about defense in depth and you mention 2 network security controls, IPS/IDS and traffic encryption. This is the youtube level knowledge of defense in depth. So basically you have 2 security controls in one of the layers of defense in depth. Can you call it defense in depth? well innacurate but yeah... I didn't complain about it the first time you wrote it, but then you were so arrogant to say that you know what defense in depth is and I had no idea.
So where it is configuration and vulnerability management in defense in depth, they are in the host/device/compute layer.
And configuration management (hardening) involves many things but basically is ensure the secure configuration of the assets. for example you can follow the recomandation of DISA, or CIS or whatever you preffer
Complete STIG List (stigviewer.com)
Red Hat Enterprise Linux 8 Security Technical Implementation Guide (stigviewer.com) Sadly there is nothing for slackware becuase is not used by almost anyone but most of the controls are valid among different distros. In any case you have the same for ubuntu, debian, suse...
Bonus track, I'm sure you know how an IPS works, and that 90+% of the rules of the IPS are created to work with unencrypted traffic, so in order to have an effective IPS you need to do SSL offloading (traffic decryption) in you IPS, if not only a few basic rules will work and app detection based on SNI (which can be easily faked). The same happens with a WAF.
So if you want to use the IPS to be effective you have to deploy certs in unraid, dockers, vms, ideally deploying an internal PKI and configuring ssl offloading or traffic decryption in your FW (in case the IPS is there).
-
4 hours ago, DivideBy0 said:
My stuff is behind the firewall and in a DMZ. Nothing is allowed inbound including the UnRaid cloud plugin. My IPS/IDS can and will see and block anything inbound/outbound. Is called defense in depth, multiple layers of defense. That being said I am to lazy to do this but have at it and report back:
nmap -sV --script=vulscan/vulscan.nse www.example.com
nmap --script nmap-vulners/ -sV www.example.com
https://securitytrails.com/blog/nmap-vulnerability-scan
Unless you are doing ssl offloading in your IPS, is going to see only the 1% of what is happening.
That is your use case but I guess many people publish or want to publish services hosted in unraid to internet, and vulnerability and hardening in the host is also defense in depth.
Nmap won't detect anything serious or not obvious but you can use Nessus scanner essentials for free up to 16 IPs.
-
Is docker vdisk (docker.img) a concept introduced by unraid or is a native feature of docker?
I have been trying to find documentation regarding this on google but I can't find anything.
-
With the small footprint of unraid it wont happen't even weekly but it will happend.
Writing a few mb in a USB stick won't broke it, it could still last a decade if you look at the TBW specification of the devices.
That "strange" idea of compose is the way docker is meant to be run, and is more convinient and easier to manage than "docker run", it's a standard. For the users would be transparent, for the community apps, maintainers or more advance users, would be a complete advantage.
-
1
-
-
Just now, MAM59 said:
cool down 🙂
Yeah, UNRAID is not bullet proof, but rather cheap and almost working. The problem is (as usual) that people demand fancy things that do not really belong here (focus should stay "fileserver"). The more you add, the weaker it gets. And you end up with so many possible configurations that are not able to be handled anymore.
Sometimes it is worth to say "NO" to new feature requests or even throw out weak stuff again.
People always expect "the egg-laying-wool-and-milk-giving animal", but this is hard to create and usually also not desireable.
LoL so a minimun security is a fancy thing?
I'm not asking to add anything in the distro, not a single new package. If they don't plan to do a properly support of the distro an alternative would be to base Unraid in a distro that will do what work for them.
You could still build unraid base on Arch, using exactly the same packages but you will get security updates in hours not months.
-
1
-
-
On 10/8/2023 at 8:56 PM, primeval_god said:
Consider instead that unRAID is not "a server" os but rather a "home NAS appliance os". It is more spirituality akin to the Synology OS or whatever runs on QNAP. It doesnt provide all the administrative tools of a more general linux os because the user is expected (though not required) to administer their NAS within the unRAID paradigm. It lacks many of the more sophisticated security tools because they are generally unnecessary for a home user on a home network which is unRAIDs target audience (alibi the more advanced home user).
A flexible distro is, I think, exactly what unRAID is trying to avoid. Slackware's lack of simple package management is a benefit to unRAID in that it helps to enforce the "dont modify the base os" tenet.
One of the benefits of dockerman is that it steers users toward the unRAID way of using docker, i.e. single container apps, bind mounts instead of volumes, simple network topology, curated apps from an appstore. Again geared toward the home user rather than the professional.For my money I would rather see limetech focus on improving the core NAS capabilities (though not ZFS, way to much time spent on that already) and commit to faster / more security patches between feature releases.
I know exactly what Unraid is, but whatever you want to call it, is still a server.
I'm refering to the intrinsic securty of the OS, not to the addition of other security tools.
The concept of dockerman is fine, the problem of dockerman is that is based on docker run and not docker compose so you have to rely on unsuported and community dockers instead on the offial ones in many cases, particularly when the app requries more than one container. So you still use dockerman the same UI but the backend should be docker compose.
NAS capabilities is the only thing being developed in Unraid the last 4-5 years, or even more. Docker, VM's, networking, etc are untouched.
Regarding CVE and security see my post above.
-
1
-
-
On 10/8/2023 at 9:10 PM, DivideBy0 said:
This argument is dead in the water from the beginning
Says who that UnRaid is not secure nor stable? I would start with that first
Nothing to see and nothing to debate here, end of story.
Do you consider Unraid stable? Do you follow what happens in the forums after each release?
Unraid not being as secure as a standard distro is a fact for 3 reasons:
Unraid devs have stated several times in the forums that Unraid is not intended to be used to publish services to internet. Why? at least 2 reasons but there could be more
a) Unraid doesn't go through any hardening process, redhat, ubuntu are verified against security frameworks (DISA,CIS) before release to ensure that the defaults are safe. Unraid does not, we just asume that the OS is safe, but actually no one knows, no ones cares.
b) Have you ever seen an extraordinary release of Unraid to patch a CVE? I have never seen one and I have been around many years. The CVE persist in unraid for weeks or months just waiting for the next regular release to be patched or not. With a "standard" distro you get those in hours.
This is a fact, end of the story 😊
-
1
-
-
I think this draw is more clear
In this case the containers inside the docker bridge network would be visible to the firewall?
Or docker bridge mode will NAT everything?
I mean if a container in docker 0 communicate with a container in docker 1, what source an dest IP will I see in the firewall?
-
another question
if the variable TZ is defined in the env file as TZ=whatever
since both have the same name, will this work?
or do I need to declare it like this
- TZ=${TZ}
I think it works but I can find it documented... so...
-
with compose it looks like this is working
volumes: - /mnt/user/Docker/Plex:/config - /mnt/user/Video/Películas/:/media/Películas:rw - /mnt/user/Video/Movies/:/media/Movies:rw - /mnt/user/Video/Series/:/media/Series:rw - type: tmpfs target: /transcode tmpfs: size: 2000000000I don't see disk writes while transcoding by plex, but If I remove them I can see a constant 1-2 mb/sec of writes by plex transcoder process in htop.
Is there any other way to check that is working? it looks like tmpfs is not using /dev/shm
-
13 hours ago, primeval_god said:
Not a bug, the compose manager plugin is an opinionated management gui. It is intended to only manage compose stacks created via its own interface, which always use the same naming scheme for the compose file and supplementary files.
Anyway I just thinking further in case someday I migrate docker compose out of unraid.
Another question is regarding the env file
https://docs.docker.com/compose/compose-file/05-services/#env_file
Are you doing something in the background so the env file is loaded automatically if it in the same folder than the docker-compose.yml?
If I migrate this to a generic docker compose installation will I need to add "env_file: .env" under the services section? or if it is in the same folder is a native behaviour of docker to pick it up automatically?
I really appreciate your patience with me
-
On 10/3/2023 at 9:17 AM, MAM59 said:
No, but all other distros are also bad.
UNRAID should use a "real" os instead like FreeBSD (not fancy, but rock solid and with the same directory structure for the last 40yrs).
Everything on Linux is added from different sources, see ZFS now beeing a real cripple on UNRAID. Why not using an OS with native support for it? Even for boot partitions.
Or networking, more or less everybody in the world is copyiing BSD stacks, more or less successful.
And it is the "less" part on Linux Distributions that makes me stay away from them if possible. Its the "is working on X, but lacks feature A on Y" or "symlinked to X" or "naming scheme Z". These things all slow down people, who has "learned" on Distro X cannot fully move over to Distro Y. He has to relearn a lot, this is totally unnecessary and only wastes time and brain ressources.
That doesn't make any sense, if you go to freebsd what happens with docker? and virtualization? bhyve is not as good and tested like kvm.
With a linux based OS more supported than slackware it would be easier for the users to do things with Unraid that not features available.
-
ultra minor bug
https://docs.docker.com/compose/compose-file/03-compose-file/
compose manager should support alternative file names for compose files, compose.yaml (preferred)
-
21 minutes ago, bullmoose20 said:
i keep getting the following error:
version: '2' services: gaseous-server: container_name: gaseous-server build: context: ./ dockerfile: Dockerfile restart: unless-stopped networks: - gaseous depends_on: - gsdb ports: - 5198:80 volumes: - gs:/mnt/user/appdata/gaseous-server environment: - dbhost=gsdb - dbuser=root - dbpass=gaseous - igdbclientid=(redacted) - igdbclientsecret=(redacted) gsdb: container_name: gsdb image: mysql:8 restart: unless-stopped networks: - gaseous volumes: - gsdb:/mnt/user/appdata/mysql environment: - MYSQL_ROOT_PASSWORD=gaseous - MYSQL_USER=gaseous - MYSQL_PASSWORD=gaseous networks: gaseous: driver: bridge volumes: gs: gsdb:are you building you own image? can you use one from docker hub?
So that leaves my UnRaid vulnerable / flying blind at SSL mercy. Enlighten me now what's the worse can and will happen with my UnRaid over SSL. Keep the facts objective, quantitative and not what you read or what you heard 
Change boot order to avoid NICs
in VM Engine (KVM)
Posted
This is the solution
https://askubuntu.com/a/226499