(I'm a Muslim). I mean... Strictly speaking as far as i am aware the mat/rug is not sacred itself. It is just a place to put your head +knees comfortably.
In fact the Prophet Muhammad SAW did not use a prayer mat and instead he placed his head on the soil (ground/earth).
Yes, the prayer rug is not sacred, per se, but it can be embued with a measure of sacredness by our practices upon it.
Please know that Zikr (remembering/repeating one of the many Names of God) is the highest form of worship. (Zikr is commanded three times in the Quran-i-Kerim.)
Al-lah, Yah-weh, Di-os, De-us, Brah-man, ...
Many Names in our various languages for the one Creator, one human race, one religion of God: compassionate service to all mankind that comes in many forms across our planet's cultures and epochs.
Always love. Teach to always love. Never hate. Teach to never hate.
Yeah I think the author of this article had some subjective understanding and experience. I don't mean to diminish it but it's definitely something I and other (but not all) Muslims find foreign
Muslims say that Islam _was_ the religion of all the prophets you've mentioned. Because of this they also believe that Islam is the _oldest_ religion, since Adam, the first man, followed Islam.
“Islam” as a named religion with its own prescribed rituals and laws is specific to the message preached in Arabia in the 7th century.
“Muslim” is a more transcendent term that encompasses all the prophets mentioned in the Quran, as well as those not mentioned. Their creed and state of mind (absolute submission to God’s will) is the same, but they did not follow a religion called “Islam”. Earlier prophets and their followers prayed, fasted, and gave charity. Some even made the pilgrimage to Makkah. However, certain details of these rituals may have differed between them and today’s Islam, and between one another.
I don't see why "Islam" could not also be seen as a transcendent term, in that any religion that was revealed by God through a prophet or messenger is Islam, in so far as that religion conforms to His will.
Quran 3:19 Indeed, the religion in the sight of Allah is Islam.
Not sure how I feel about the HTTPS/TLS related bits. These days anything I write in Go uses plain HTTP, and the TLS is done by a reverse proxy of some variety that does some other stuff with the traffic too including security headers, routing for different paths to different services, etc. I never run a go web application "bare", public facing, and manually supplying cert files.
I suspect this is partially from google's internal 0 trust cluster networking.
I.e. even if the communication is entirely between components inside a k8s (or borg) cluster, it should be authenticated and encrypted.
In this model, there may be a reverse proxy at the edge of the cluster, but the communication between this service and the internal services wouls still be https.
With systems like cert-manager it's also incredibly easy to supply every in-cluster process with a certificate form the cluster-internal CA.
This might be me being daft, but I never quite understood the appeal of doing this with istio.
OR also partially just due to the timing of when I started to care about things in k8s world. (Rather recently)
My understanding of that model is that the services themselves still just do unauthenticated HTTP, this gets picked up on the client side by a sidecar, packed into mTLS/HTTPS, authed+unpacked on the server sidecar, then passed as plain HTTP to the server itself.
This is great when we have intra-host vulnerabilities I guess. But doesn't allow to e.g. have code sanitizers that are strict on using TLS properly (google does this).
And while it is a real gain over simple unauthed with untrusted network between nodes, with cilium taking care of the intra-node networking being secure, I don't quite see how the added layer is more useful than using network policies strictly.
(besides some edge cases where it's used to further apply internal authorization based on the identity. Though that trusts the "network" (istio) again.)
For us it’s compliance related first rather than any real security upgrade; we must use mtls between all services (finance) and it’s simply less to manage to use a service mesh.
The cloud provider could read the memory of a k8s node and in theory capture the session keys of two workloads on the same node, and we can’t really protect against that without something like confidential computing.
We get some other benefits for free by using istio though like nice logs, easily sending a chunk of traffic to a new release before rolling it everywhere, or doing fully transparent oauth even in services which don’t support it (oauth2proxy and istio looks at the jwts etc).
in the modern world extra network hops, novel userland network stacks, and additional cycles of decrypted/re-encrypting traffic make your apps go faster, not slower.
Not sure if it's ironic or not. Because it should be not.
AES-NI gives you encryption at the speed of memcpy basically. Userland network stacks are faster because they don't incur the kernel call cost. With that, if your NIC drivers support zero-copy access, an extra hop to a machine in the same rack over a 10G link is barely noticeable, may be shorter than an L3 miss.
The cost of this is mostly more hardware and more power used, but not much or any additional latency.
Because it’s zero configuration auto mtls between all the services in your cluster (or intra-node if cillium) instead of managing a tls cert for every service?
Zero to little configuration at point of use, but a lot of upfront configuration, maintenance, fun issues when you need something slightly less traditional (e.g. something that needs raw TCP or heavens forbid, UDP). Different trade offs for different situations.
At least in our org security let us know when it's time to patch various components and it's typically just a devops chore to bump a helm chart version and merge..
I don't really understand your point; You're trying to say managing a single helm release for istio is more effort than (in my case, for example) manually managing around 40 TLS certificates (and yes, we have an in-house PKI with our own CA that issues via ACME/certbot etc also) and the services that use them? It's clearly not?
Just templating out the config files for e.g Cassandra or ES, or Redis or whatever component takes multiple x the effort of ./helm install istio.
Istio is a notorious pain to maintain, because it has a bunch of dependencies around Kube clusters, so you can't just helm install istio every time there's a new release.
I have use cases for both approaches (letting a reverse proxy handle TLS, letting the application listen on an external socket and handling TLS in the application).
I find is is easier to configure an application with a reverse proxy in front when different paths require e.g. different cache-control response headers. At the end of the day I do not want to replicate all the logic that nginx (and others) already provide when it integrates well with the application at the back.
Other commenters suggest that both ways (with or without additional reverse proxy) add "tons of complexity". I don't see why. Using a reverse proxy is what we have done for a while now. Installation and configuration (with a reasonable amount of hardening) is not complex and there exist a lot of resources to make it easier. And leaving the reverse proxy out and handling TLS in the application itself should not be "complex" either. Just parse a certificate and private key and supply them to whatever web framework you happen to use.
While I understand the sentiment, this makes bare installations too hard.
A big project not handling HTTPS themselves (like docmost), adds tons of complexity on the server side. Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc.
That leads to resource inflation when I just want to use a small VM for that single task. Now, instead I deploy a whole infrastructure to run that small thing.
Handling https in the project also adds tons of complexity in the long run though: tls/ssl library versions, cert handling. Instead of having one way to deal with all of them (at the proxy layer, or sometimes at network layer), I have to deal with individual software way of managing those
Do that for a bunch of different applications and you hit interesting issues. For example the Java TLS stack, which doesn’t accept a PEM certificate on its own, but needs the full certificate chain. Kibana, however, requires the full certificate chain including the root certificate, which isn’t usually a part of the certificate itself, and Elasticsearch complains about an invalid certificate if you point it to the same one.
So even for two apps from the same vendor, which are commonly deployed together, you need bespoke TLS file variants. Scale that to more applications, and you’ll find out the hard way that you are vastly underestimating the complexity of operating a software ecosystem.
I’ve done it. What you’re describing is like an hour of work. Moving TLS outside of the application is possibly the dumbest reason to spend the resources and complexity on a side car.
For a single application, it's not too bad. When you have dozens of applications that all have different mechanisms to install a CA, rotate certs, etc. And some of those don't have a good way to automate rotating the certs, then it becomes a pain.
I don't think so. We run a horde of machines, and run plethora of services, which are custom and/or has a very narrow install base due to the niche they serve.
99% of them use system-wide PKI store for CA and their certificates, which is under /etc. All of them have configuration options for these folders, and have short certificate lives because of the operational regulations we have in place.
At worst case, we distribute them with saltstack. Otherwise we just use scp, maybe a small wrapper script. Managing them doesn't take any measurable time for us.
> 99% of them use system-wide PKI store for CA and their certificates, which is under /etc.
Consider yourself lucky then.
For self-hosted third party software, I've seen requirements to provide it in an environment variable, upload it to a web form over plain http on localhost, specify an AWS secret service secret that contains it, put it in a specific location that is bind mounted into a container, create a custom image (both VM and container), etc.
I mean, tons of "old-school" services handle these things fine for the last two decades, at least. It can't be that hard. It's just a TLS library, and some files in a specific format at the end of the day.
In my experience, most people have an extremely hard time wrapping their minds around how to configure TLS/HTTPS services and fail completely at understanding how it works.
Because some of the applications are "container native" and do not support configuration of IP/Port binding. Why? UNIX philosophy and working traditions be damned.
I can understand the reverse proxy, but I want to run thing on a small VPS or a Raspberry Pi, etc. I want to use minimum resources so I can run more things per server.
If this thing was being installed at work, I can build a great wall in front of it, but for personal things, I rather have less moving parts, and just deploy and forget the thing.
> Because some of the applications are "container native" and do not support configuration of IP/Port binding. Why? UNIX philosophy and working traditions be damned.
I'm not sure I follow. Docmost runs in a container, on a port which is configurable. By default, as all containers, that port is local to the container. The container orchestrator (be it docker CLI, docker-compose, Swarm, Nomad, Kubernetes, Podman) is the one who you instruct to expose a port from the container network to your host network. Docker tries to be smart and easy and will expose it on all networks by default, but even on it it's configurable, let alone on the more advanced options.
First, any enterprise/homelab installation with significant resources is outside of my scope. I don't care about them. When you don't pay for the infra/power cost, all bets are off. You can install quadruple redundant 300 node K8S cluster sitting on two different data centers in different cities connected to their own power generation equipment for a simple docmost instance.
I'm talking about small fry installations, for personal reasons, on small equipment. Think Raspi5/N100 NUC boxes as the target hardware.
I have limited resources, want no heat/noise at my home or want to pay as small as possible for a good VPS. Now, for something like docmost, I need a container runtime, and ingress controller/a reverse proxy, because I want to open this service to a VPN or web somehow.
I don't have much qualms with containers, as long as there are no cut corners. We'll talk about two examples here.
First is Wiki.js. Comes with 3 containers. DB, Wiki, Updater. OK. They are not much resource heavy, so acceptable. On top, Wiki container handles its own HTTPS, TLS certificates via Let's Encrypt (and allows custom ones, as well). It's the nice one. I can expose it, or hide it, I can handle my certificates or it can handle itself. Nice, batteries included. Install in 10 seconds, update occasionally, enjoy.
Second is docmost. It's a nice tool. Allows me to create a space and put a bunch of people in to collaborate. Install for desktop in 10 seconds & Works. Nice. I want to open it to outside. Forward a couple of ports? No. There's no HTTPS. Now I need to terminate it. Traefik? Too big for the job. Apache, doable but needs half an hour from get go. Can I limit it to localhost for local installations, for myself? No. As long as I run it, it binds to 0.0.0.0. So, if I want to install it locally to my desktop, I still need to add a firewall in front of it, because whole LAN can see it, and no, I don't trust any devices on my network (not people, but the apps).
This is my problem. I want batteries included solutions, which can adapt to my circumstances. I don't have the desire to run n servers for m services, because they are too lazy to be flexible to adapt their environments. It's not I can't do it, it's the contrary, but I don't want to, because I want to live my life and have time for people and things I care.
The services I use must be able to adaptable to my environment. This is how bare-metal services, daemons in UNIX world work. I can fit a whole rack of services in a powerful enough server and isolate them if required. It saves space, power, time and sanity. Littering services with services in boxes and putting more boxes on top of that because their developers are lazy makes my blood boil.
> Think Raspi5/N100 NUC boxes as the target hardware.
I don't think those would be negatively impacted by running Docker or Caddy. Isn't the performance cost of containers minimal these days?
I had similar thoughts in the past, but when I looked up performance comparisons between running something on docker vs without a container, the resulting performance was practically identical.
The problem is not containerization per se, I run containers both in my personal systems and at work. If you extremely optimize for compilers, the performance difference can be trimmed down to 2%. I think for most of us, it's 5%-6% band, and it's OK for non-loaded servers.
My qualm is about trimming fairly standard features and offloading it to somewhere else.
A single HTTP service + traefik (or Apache/NGINX reverse proxy) is heavier than a single HTTPS service. Plus adds more moving parts for smaller installations. f I was running an API farm, I can add all kinds of bells and whistles, and it'll be lighter overall, but this is not a valid reason for stripping fairly simple features from applications which will be used by small teams on small hardware.
Plus, this additional layers can sometimes conflict (A requires B, C required D, where B & D are same thing but either one can't accommodate A & C at the same time), requiring a completely new system to run the service, which is wasteful, from my perspective.
> A single HTTP service + traefik (or Apache/NGINX reverse proxy) is heavier than a single HTTPS service.
How heavy are talking, and what would be the measured impact?
I have worked on small teams (3~4 people) where we had to use our own infrastructure for regulatory reasons. I also self-host a few things as a hobby. I don't think Nginx or Caddy were ever a bottleneck, and at the human level, they saved more resources than not using them. I don't remember the last time I exposed something to a network using their bundled http server directly rather than a reverse proxy. I don't like wasting computational resources of course, but % wise, 'optimizing' them by not using containers or a reverse proxy wouldn't net any visible gains - there's usually other low hanging fruit that gives you more for your time.
> Traefik? Too big for the job. Apache, doable but needs half an hour from get go.
What do you think Traefik is if you think Apache is OK? It's similar in size and footprint, just modern (you can point it directly to Docker or any number of sources and it auto configures itself). I've ran Traefik with Docker containers behind it on Raspberry Pi 3s, this isn't supercomputer territory.
> As long as I run it, it binds to 0.0.0.0. So, if I want to install it locally to my desktop, I still need to add a firewall in front of it, because whole LAN can see it, and no, I don't trust any devices on my network (not people, but the apps
Come on, this took literally a few seconds to Google.
> This is my problem. I want batteries included solutions, which can adapt to my circumstances.
Which is it, batteries included or flexible? It's hard to be both, and funny you complain about that, Traefik is a perfect example of a tool that does both well.
> The services I use must be able to adaptable to my environment. This is how bare-metal services, daemons in UNIX world work
Ah, so you don't need systemd/an init and service system? Or libc? Or iptables/firewall? You just plop an app and everything magically works how you want it to?
I think you have fundamental knowledge gaps, and instead of trying to address them, or think about why would a project prefer to not reinvent the wheel everyone already has anyway, you prefer to rant that it wasn't like this in the good old days. Good old days with cgi-bin and php-fpm that needed a reverse proxy in front anyways, so nothing has changed other than an abundance of documentation and examples and flexibility.
> Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc.
You can setup a Traefik (or some other ingress service) instance in a container and let it handle all the reverse proxying thingies for you. And if you do it right, the services should automatically register to the ingress service as they start up, and a port/HTTP route should be automatically assigned to them.
Do it in the old bare is harder and probably will always be harder, since you will be directly interact with OS facilities that was probably designed for something else than what you might try to run. Container management service such as Docker and Kubernetes abstracted away a lot of these complexities.
Funny enough, Traefik is written in Go... guess we've gone some (maybe not full) cycle on this one.
Honestly, doing things on bare server and interacting with OS is easier because it involves less moving parts and everything is in a more accessible state.
Containers are not bad per se, but cutting corners just because "this will run in a container, so they can just add another HTTPS terminator" is just carelessness IMHO. Because not all of us have homelabs at home to install an onion of services to run a simple service open to outside.
A good example of this is Wiki.js. It's desinged as container native, but handles its own ingress, HTTPS and Let's Encrypt certificates. I have no qualms to it, but when another tool just cuts corners and tells you that "It's easy to install, but bring your own secure ingress layer on top", it gets ugly.
Because it adds moving parts, most importantly wastes resources for a 3 person installation on small hardware, etc. Keep in mind, these are tools designed for small user-bases. They're not enterprise software.
On my day job, we call 80 machine clusters "small". But this is not about things I install/manage at my job.
While I am not ready to recommend that everyone install Traefik, this is false.
You can get a single node Docker “cluster” going with Traefik in 15 seconds. There is no maintenance except updating occasionally. It doesn’t use much more resources. You do not need to install any third party tools. There is no onion of services. You literally just boot up Traefik plus your app.
This has been doable since at least 2019 by just installing Docker via your OS’ package manager.
I’ve started using containers before 99% of people and so got to see the fundamentals build up. You do not need to skip directly to “Kubernetes.” That’s like needing to wash your clothes so you skip directly to buying an industrial washing machine and then lamenting how all washing machines are overkill.
Traefik plus my service is two layers. My service has a DB hidden behind it, it's three layers. I put a VPN in front of it, and now it's four.
My service doesn't take much resources, also the DB I use is light by itself. I added traefik, which is also light, and the VPN daemon which is also light.
However, these four layers are not light. They're heavier. I'd rather don't have Traefik in front and have a lighter stack, because for that much resources, I can run another server at another port, which can save me another VPS (money, maintenance time, documentation and interconnection).
I mean, we were using jails before Linux had containers. I'm not new to system administration or computers in general.
I don't get angry because things are complicated/hard. I get angry because we waste resources and write bad software because we somehow think "worst is the best".
Things add up. Light becomes heavy, easy becomes meaninglessly complex. This shouldn't be like that.
Are you mad because everybody is down voting your 42133422 post to shit, so you're down voting everyone who replied you? Don't do that, because it will only give you more down votes.
> it involves less moving parts
Every sane person who experienced a few server updates will not put out claim like that. One day you ran `apt upgrade -y`, minutes later 30% of your clients PHP website somehow went down? "less moving parts"?
In fact, Docker was invented to address this exact "it worked on my machine, why not yours" problem, by actually introducing "less moving parts".
> cutting corners just because "this will run in a container, so they can just add another HTTPS terminator" is just carelessness IMHO
Stop trying to misrepresent anything. No one is trying to solve a problem by wrapping HTTPS terminator with "another HTTPS terminator". Also, for real, how can you terminate HTTPS twice?
Also, from your another post:
> Traefik plus my service is two layers. My service has a DB hidden behind it, it's three layers. I put a VPN in front of it, and now it's four.
Why stop there, if you start from user's keyboard as a layer, then there's 5, and screen 6, then countless Internet cable and routers. Man! so many layers, it's crazy!
Also, that's not how you structure things. You have a reverse proxy, and then a service, 2 layers total.
Alright, alright, please, just admit that currently containerization is not a technology you can correctly take advantage of, and then you go ahead and learn more about it. It will be an useful tool for you, as it did for many, I'm sure.
> everybody is down voting your 42133422 post to shit
They can, we don't have to agree on everything.
> so you're down voting everyone who replied you?
You can't downvote replies to your own comments, plus I don't downvote people because they have a different view than mine. Heck, I don't downvote as a principle. As long as the comment needs a flag, too.
> No one is trying to solve a problem by wrapping HTTPS terminator with "another HTTPS terminator"
Ow. I say "people don't add https functionality to their code, because they expect it to be done elsewhere, and that's bad practice". Do you read what I have written?
> Why stop there, if you start from user's keyboard as a layer...
Who said I use a VPN to connect to my database? I have a closed/dark network of hosts on different locations sitting behind a NATs forming a personal network. This is what that VPN is about.
> Alright, alright, please, just admit that currently containerization is not a technology you can correctly take advantage of, and then you go ahead and learn more about it. It will be an useful tool for you, as it did for many, I'm sure.
Alright, alright, please just admit that you didn't understood a single bit of my posts, and can't paint a picture of what I'm talking about, and then you go ahead and read it all again. It will be a useful exercise for you, as it did for many, I'm sure.
Now I need to clean my keyboard of this coffee, and need to handle my OpenStack cluster. Oh, boy...
I wonder what the common factor between these people is (besides their skin-tone I mean).
Because surely there must be some kind of census or survey or company that had collected phone numbers and people's race information at some point. And it either got leaked or was intentionally created to harvest the phone numbers of black people?
The question that comes to mind is what percentage of black Facebook users have their phone number on their profile (only visible to their friends) and have also friended a bot? (or joined a group that compromises their security?) A fraction of a percent is still enough to do some harm.
> Maybe not to you, but to some people it is incredibly valuable for maintaining relationships.
Communication is incredibly valuable for maintaining relationships. Whether that's through social media, IM, calling them, hanging out in meatspace. THAT is valuable. Not merely following someone on social media.
I am in my early 20s. My highschool life (and some after) was filled with social media use and borderline addiction. I added people on social media that I kind of knew, or talked to once, or wanted to talk to.
But literally none of that kept me in touch with most if not all of them. More than half of them I never messaged, never interacted with on social media.
What kept me in touch with them was me or them. I deleted all my social media. And the ones who make the effort to contact me out of social media? Those are the real relationships.
Well, it’s just anecdotal, but a distant relative of my ex was imprisoned after being coaxed by FBI agents into attempting a mass shooting with a pellet gun. He was arrested walking out of a Walmart with his new pellet gun.
He is a disabled person clearly not qualified to buy firearms. The store would not sell him a real rifle on his first attempt, so the FBI agents told him to buy a pellet gun.
It would have been a “hilarious prank” if he didn’t end up spending 3 years in federal custody. TBF he was probably a lot better off in federal custody than in his normal day to day, so hard to say if this was really a bad thing for him.
Still, it’s frustrating to know that the resources of the FBI are spent on pranking disabled people.
>Critics say the FBI is running a sting operation across America, targeting – to a large extent – the Muslim community by luring people into fake terror plots.
>Every day was the same for Khalil Abu Rayyan, 21, a depressed pizza delivery man from Dearborn Heights, Michigan. Working for a pizzeria in Detroit, he’d drive late nights on desolate inner city streets...
>“We are tremendously pleased that our clients are on their way home -- even if it’s fourteen years too late,” said Amith R. Gupta, part of a group of lawyers representing Payen and the Willamses, who are not related. Gupta in his statement described the three as destitute men “entrapped for their race, religion, and working-class backgrounds by a government looking to spread fear of Muslims and justify bloated budgets.”
This is my point. This exact thing happens for these non-white terrorists, but the excuse of FBI coercion does not come up in public opinion (e.g. comments here, around the web) as a valid excuse for the perp's actions. The discussion is had but it's never considered as a _valid_ excuse unless they are white.
I agree in that there's hypocrisy on either side. You'll also find commenters on this site who cite the FBI claiming, "White supremacists are the number one terror threat". Meanwhile, mass media pundits sought to paint all of their political opponents as racists. Comments echoing that talking point were also prevalent on HN. Thankfully, that narrative has mostly moved out of popular imagination.
From my perspective the pendulum swings between targeted groups. Each respective group has their turn to run the gauntlets of media demonization and security service targeting. Many of the same people who were cheering the expanses of the security state during the heights of the War on Terror clutch peals when the pendulum swings back upon their demographic. Each tribe has their chance to shout down the 'others'. We shouldn't be surprised if similar tactics are used to pursue the formerly favored BLM activists in the coming years. The only constant is the expansion of the security state. Classic divide and conquer.
The FBI has been running this playbook since at least the 50s. Other commenters on HN have rightly compared it to Soviet internal security policies. There's nothing truly new under the sun. Human nature is tribal and there will always be those who seek to exploit it to gain power. The judgement of whether this is deliberate or the result of natural incentives such as career advancement and political necessity is an exercise for the reader.
In fact the Prophet Muhammad SAW did not use a prayer mat and instead he placed his head on the soil (ground/earth).
Also note; Shias place their head on a stone/rock to mimic this practice: https://en.m.wikipedia.org/wiki/Turbah