I'm trying to test a DAG I wrote in Astronomer/Airflow but I'm getting a really peculiar behavior that has me totally stuck.
Airflow's webserver comes up, and then after login as admin it redirects to http://localhost:8080/home which doesn’t appear to exist.
The specific error I get in the browser is ‘too many redirects’. I’m sure something is wrong in my configuration, but it’s not obvious (to me) what. Can you suggest steps for further diagnosis?
Thanks,
Keith
I thought I would share the resolution of this problem in case anyone else encounters it.
This problem came about while developing a DAG to test a part of our pipeline. The repo I was working with used a Dockerfile which was designed for automated testing and was not suitable for a DAG. Once I reverted to the stock Dockerfile the problem went away and I can now load localhost:8080/home just fine.
I have had similar issues when the username or the password is incorrect. I am expecting you are either entering wrong login credentials or your configuration is checking some external authentication server and it is not configured correctly.
Related
EDIT1: intershop.urlrewrite.CheckSource is turned off already
We are recently having quite big problems with URL rewrite rules not being loaded in test and production multi-node environments.
The problem started happening after introducing another organization and it's related application onto the servers.
From then on we have tried multiple changes and debugging methods to try to figure it out, but without any result.
Also the major problem is that it doesn't happen all the time and server restart can fix it but not always.
Here are the details so far how the problem manifests (this has been going on for more than a month now on our production system):
Most of the time it starts happening after the deploy of new code and starting up the server
Then multiple people from multiple computers and locations try opening the website and some open it and others get either 404 or "URL invalid" page, so its 50/50.
On the PC where someone successfully opens page, if you try again in incognito mode then you may get again 404(probably connects to another node/appserver).
Usually the problem is resolved either by server restart or by restarting a single node(no code or configuration changes) although this is no reliable way and on the last occurrence we tried multiple restarts and it didn't help. After a few days one of the team members restarted only a single node for debugging purposes and then it started working normally again.
After setting up more detailed log messages and turning on debug messages for URL rewrite classes we have come to the conclusion that the rule loading fails. We have come to this conclusion because we have added debug message on the very start of our applyExpand() method and it never gets shown. This can be observed on the image below:
All of this leads to conclusion that iterator on line 149 is empty.
Please advise on possible causes of this problem and how to resolve it.
The rule loading is implemented so that it's possible to edit/add/remove rules on-the-fly without need to restart the web server. This happens when the property intershop.urlrewrite.CheckSource is set to true. For this, the last-modified time of the file is evaluated. Maybe this doesn't work correctly.
I would recommended to set this property to false and test again if the problems still occur.
With the help of IS support, we have managed to figure out that the problem was that the URL rewrite rules were in a cartridge that wasn't part of every possible application on server which would result in undefined behavior when loading them (it would load on one appserver and on another it wouldn't).
The fix was to add a new common cartridge for all possible applications which would then hold urlrewrite rules and which would definitely be loaded on server startup.
I shared a link with someone to a firebase site that I was hosting, and it worked for some time, but then all of a sudden they said they were getting the message:
We're sorry... ... but your computer or network may be sending
automated queries. To protect our users, we can't process your request
right now. See Google Help for more information.
I was also getting it, and started checking my other firebase hosted sites and started getting the message on all of them. I didn't understand. I couldn't find a common link to understand why it was happening. So many sites linked it to a reCAPTCHA problem, but my sites don't use reCAPTCHA...
I found this link:
GitHub forum Link
The user recommended making sure the url started with "https". As soon as I typed my url with "https://" at the start, everything came up. At that point, I tried all the other URLs, and they worked too. This may be a rule for all Google-related sites.
I'm not sure if it's relevant that Chrome often trims the url in the "omnibox" or address bar, hiding the protocol, making it easy to miss when copying/pasting? E.g. :
Note, I tried accessing these pages without https (by typing "http://") but my browser now seemed to correct it and force it to be "https://", so I couldn't replicate the problem again.
I don't know exactly why it started, but I know that I wish I found this information sooner, because it was very frustrating, and the info out there wasn't helpful, except for the link I posted above. So hopefully, when someone like me searches for "firebase" and the error text "your computer or network may be sending automated queries", they might see this and possibly be saved a headache.
I've been filtering through google to try to find an answer to this, but I still can't find one that fixes my issue. I have migrated a website to a new server. The framework is Symfony 2.8 on php5.6 using Nginx and PHP-FPM.
Here is a screenshot of the config.php page.
To resolve this, i've tried...
Changing the user for Nginx and php-fpm to both the user I log in with and Nginx, both didn't work
I've opened up the privileges on the cache and log folder to 777 within the app folder, and that didn't work, nope.
I've tried assigning the cache and logs folder to nginx:nginx, no go.
I've manually assigned app.php, app_dev.php, and the console file to have the umask(0000) and umask(0002), nope.
Restarted the Nginx service and php-fpm service after each change, nodda.
I've restarted the entire server thinking something might be stuck, but you guessed it. No!
That leaves me here. I've gone through everything that I can think of and it baffles me that Symfony still won't recognize the directory as writable. It seems like the most simple thing, but... nope.
Anything will help, please pass anything along.
After countless hours of research and scraping the internet for details, I have found the answer! I'm posting it here in case someone else is having the same issue... and hopefully I can save them some time. This took up two days of my life that i'll never get back.
For whatever reason, SELinux was causing this error. I came across this issue on superuser stack exchange, and it told me to temporarily disable SELinux to test. After running sudo setenforce 0 everything came back up. I then completely disabled it and everything has been working fine since.
This happened suddenly and i'm still unsure of the reason. The site worked for about a week before this was triggered.
You should read this to setup you directories permissions http://symfony.com/doc/current/setup/file_permissions.html
I always go for the point 3. with Debian/Apache, Unfortunately i never tried it with nginx.
I have a problem when placing an App module(v 8.4.8) on a page. When I placed an App module on a page I got a pop up saying "Had an error talking to the server (status 404). if you are an advanced user you can learn more about what went wrong - discover how on 2sxc.org/help?tag=debug".
This error happens on whatever action I try to do: trying to add and app, refresh page etc.
I checked a communication to the server using Firebug and seems that one of APIs are missing:
~/desktopmodules/2sxc/api/view/Module/GetSelectableApps
Referer: ~/desktopmodules/tosic_sexycontent/dist/dnn/ui.html?sxcver=8.4.8.19191
Did I missed something? Should I make some configuration after SexyContent module install (v 8.4.8)?
I just checked a video by Daniel Mettler where he showed how to install a module and seems that process is simple. Nothing to worry about.
Does anybody has any idea what might went wrong here?
The same actually happens when I install and Content module: Error about missing APIs:
~/desktopmodules/2sxc/api/view/Module/GetSelectableContentTypes
~/desktopmodules/2sxc/api/view/Module/GetSelectableTemplates
Thanks a lot for your time
My best guess is that it's an issue with the dnn domain/path configuration. So basically my guess is that
you have multiple domains, and if this is configured incorrectly, the paths in the js-calls won't fully match the original one
you have sub-portal (with paths like /products/) or something, and this isn't configured correctly in dnn
languages in portal-paths are causing similar issues.
So please compare EXACTLY the full base path and see if that's the issue.
I am building a Symfony2 project, using FosUserbundle and have a serious security issue. When a user tries to connect, it correctly redirects to the home page when the credentials are correct, but most of the time without actually loading the user, still with the anonymous token, not logged.
It sometimes logs me successfully at the first try, usually after 2-4 attempts, sometimes more. It seems to fail 70 to 80% of the time.
There is no error message at all, everything seems to work just fine, except it doesn't. I cloned my project without FosUser, using the login and security system in the cookbook in the documentation on the Symfony website, still the same.
The application has been developed with Symfony 2.3, but upgrading to 2.6 and 2.7 doesn't solve the problem.
The security code is completely vanilla except to extends my template in one twig file, and the behaviour is still the same without the extends.
The config files have been modified according to the FosUserBundle doc.
I am obviously missing something, but no idea what.
After a couple of week, it stopped doing weird stuff, that is good, but no idea why, that is not so good.
As i have said, the config files are straight out off the official doc. If they were at fault, i think that dozens would have had the same issue.
For the curious, it started doing weird stuff while i was playing with websockets and Ratchet. I don't know if it give an idea to someone as to the why.