Admin Html

[Bernice Ebesugawa]

Iam making some progress. Having started with a completely new nethserver installation, I installed nextcloud. Then collabora-online. I made sure that lethsencrypt is in place and virtual host is set to lool.ourdomain.com.

After following the documentation I now am able to access the admin page, which asks me for a password. Initially it did not accept the password, not even with private tab. A reboot of nethserver fixed that. So I am now able to login and see the admin page @

Andy, I have a question. I checked with my private gentoo server where I have collabora online successfully running on the same host, as nextcloud. I had to setup proxypass, and following the relevant part of my vhost configuration:

As I am able to see the admin page of lool admin interface @ as described in the documentation (it asks for username and password and providing them, I can login!) could it be, that in opnsense is blocking something, thus it is not working within nextcloud? Do I need to configure opnsense for port 9980? And if so, what port forward rule should that be?

As said, all prerequisites are working, the final part, that is not working is after activating the collabora online connector app within nextcloud I cannot open an office document within my nextcloud instance on the nethserver nextcloud.

Well, I thought so too, but do not know, how to acheive this. Only if I could set a rule in opnsense temporary to open up every port just for testing, but how that rule should look like? On the other side, I mean the proxy pass thingy is to just for localhost ip so it seems strange if opnsense would be the blocker.

I had another idea to test, which almost makes me sure, it cannot be a problem on opnsense. You know why? I tried the same test from within my vm on the green network, that way opnsense should not be in the way, right? And its the same thing, so it might have nothing to do with the opnsense firewall after all?

I still hesitate to change opnsense rules as I am afraid by doing it wrongly, I cut my connection to ssh. I will think about for good before proceeding and in the meantime I also will try to activate some logging of loolwsd that maybe could give a hint of the real source of the problem.

As a security precaution I may even switch the /etc/network/interfaces to the one, I directly access the host bypassing opnsense. That way if anything goes south, I reset the host via webinterface and can re-establish connection as the host gets the ip directly after reboot.

Also, you now see why I dislke having a firewall running on my Nethserver. Even with AD (a virtualization inside a virtualization) things can get difficult, let alone using additional ports and proxies.

Off topic: Looked at the last 500 lines of /var/log/messages. omg

I definitely have to change ssh and disable passwordauth thus switch to cert based on the nethserver too as I have done already longtime ago for the host system. Way better than enabling fail2ban to eliminate all those useless logentries.

Can we not have this be hidden through PMs. If a exploit exist its paramount that this is all kept in the community eyes so others can assist and chime in. Users need to know if some new exploit is discovered or not.

Can we get some more details on this? Such as what is the attack vector in FOP2? Does this impact FOP2 instances running on HTTPS? Was this the user or admin interface that was compromised? What version of FOP2 is this happening on?

The second box had a new version of FOP2 installed back in 2020, that one is running and has the latest release (2.31.33), it was running 2.31.30 before that. There is no ko.php or index.php file in the lang directory.

On the compromised box, it happened back in 2019 based on the file dates. About 8 months before I did a new install on a different system and just moved the license. So do you have an index.php in your lang directory? What is the timestamp on the ko.php and index.php (if you have one)?

Killed services. Deleted files. CPU down to 0.1, from 12.5. Trying to anticipate the next move to ensure tomorrow is not a difficult day. I have email Nic at Asternic and waiting for a response. I referred this page for better data than I am capable to providing alone.

First - I know that this question has been asked and answered before (see Django: Overriding AND extending an app template) but as the answer says it isn't directly applicable if you're using the app_directories template loader (which is most of the time).

My current workaround is to make copies and extend from them instead of extending directly from the admin templates. This works great but it's really confusing and adds extra work when the admin templates change.

I had the same issue about a year and a half ago and I found a nice template loader on djangosnippets.org that makes this easy. It allows you to extend a template in a specific app, giving you the ability to create your own admin/index.html that extends the admin/index.html template from the admin app. Like this:

As for Django 1.8 being the current release, there is no need to symlink, copy the admin/templates to your project folder, or install middlewares as suggested by the answers above. Here is what to do:

Note: The location of this file is not important. You can put it inside your app and it will still work. As long as its location can be discovered by django. What's more important is the name of the HTML file has to be the same as the original HTML file name provided by django.

In this example, I want to modify the add new user form. The template responsiblve for this view is change_form.html. Open up the change_form.html and find the % block % that you want to extend.

I couldn't find a single answer or a section in the official Django docs that had all the information I needed to override/extend the default admin templates, so I'm writing this answer as a complete guide, hoping that it would be helpful for others in the future.

Create the template you want to modify in your templates directory, maintaining the default Django admin templates directory structure as specified in the docs. For example, if you were modifying admin/index.html, create the file templates/admin/index.html.

For example, if you wanted to keep everything as-is but wanted to override the content block (which on the index page lists the apps and their models that you registered), add the following to templates/admin/index.html:

For those templates that cannot be overridden in this way, you may still override them for your entire project. Just place the new version in your templates/admin directory. This is particularly useful to create custom 404 and 500 pages

The best way to do it is to put the Django admin templates inside your project. So your templates would be in templates/admin while the stock Django admin templates would be in say template/django_admin. Then, you can do something like the following:

And now, you can rename change_form.html to custom_change_form.html but custom_change_form.html in any folders cannot automatically apply to any admins in any apps. So, you need to manually apply custom_change_form.html to any admins in any apps which you want to apply custom_change_form.html to.

FIRST: Make a symlink named admin_src in your project's template/ directory to your installed Django templates. For me on Dreamhost using a virtualenv, my "source" Django admin templates were in:

I don't have the reputation to add more than 2 links. But I think the links provide interesting background information. So I just left out a slash after "http(s):". Maybe someone with better reputation can repair the links and remove this note.

Pay attention and use format_html (See docs here) as the mark_safe util has been deprecated since version 1.10. Moreover, support for the allow_tags attribute on ModelAdmin methods will be removed since version 1.11.

It took me two hours to find out why Daniel Roseman's solution doesn't work for me. Even though he is right, there's one exception: when you want to make custom calculated fields (read only) in the Admin. This wont work. The very easy solution (but hard to find) is to return your string in a special constructor: SafeText(). Maybe this is linked with Django 2 or with readonly_fields (which behave differently from classical fields)

Also, the template to view a question show.html.eex will be different for an admin and a visitor: the visitor will have a nicely displayed question (with different html), while the admin will have a rather raw template, using the same layout as the layout used for listing questions and editing questions.

Thanks for your help so far. I guess if that behaviour is not expected like this and permissions should work out of the box I would say the next step is to re-install container station. I am really wondering why they don't want to provide a standard docker package by default.

Ok, so just uninstalled container station, removed the container data folder, the appdata folder and did a clean install. But the problem still exists. I assume that docker is installed somewhere deep in the system.

Hi chrneu,

I had the same symptoms you describe, what solved the problem for me (see the other thread linked by diginc) was to remove the ACL on your appdata folder before creating the docker.

After that the ls -al /share/appdata/pihole lost the '+' on permissions for setupVars.conf and the web admin page works properly.

Cheers

Do you need a dashboard that is simple to maintain and easy for everyone to understand? With HTML admin templates from ThemeForest, you can find admin templates to suit your needs. Graphs? Got them. Numbers? Yep. Axis? Check.

Looking for something your staff can review on the commute to work? If so, then our responsive HTML admin templates provide the perfect dashboard to view on a cell phone. Big fan of material design? Check out the material design dashboard templates and add some style to your data.

3a8082e126