How can I change the port for Webmin access? - ssh

I'm managing a Rails website that relies on MySQL tables. I used to be able to access the tables with Webmin by going to xxx.xxx.xxx.xxx:10000 . At some point, I lost the ability to access it this way.
I'm not great with SSH, but I was able to SSH into my website as a general user. Then, I switched to Root user. Then, I ran this command to restart my Webmin:
svcadm restart webmin
It seemed to accept the command, but I'm not really sure how to check. Anyway, I started getting a new error message when I tried to access Webmin through my browser:
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
The website uses a connection with Cloudflare. My guess was that this could be the problem since Cloudflare doesn’t support port 10000. I tried deactivating Cloudflare, but it didn't resolve the problem.
Still, I figured I might need to use SSH to change the port for Webmin access just in case. I found a source that suggested how to do it, and it starts with SSH. I went in through SSH and I switched to Root user. Then, I ran this command:
/etc/webmin/miniserv.conf
And it tells me
bash /etc/webmin/miniserv.conf Permission denied
How can I get past this step? Am I headed the wrong direction to get access back to Webmin? Thank you!

Related

Unable to connect to phpMyAdmin via SSh tunnel on Bitnami LAMP stack

I've tried searching for a solution to my problem both here and elsewhere online but I've come up empty, so I'm hoping someone can help. I must initially point out this issue has shown that this area is a complete blind spot for me, so I'm sorry if I'm missing something blatantly obvious, or I'm not explaining thoroughly enough.
I'm trying to access phpMyAdmin on a Bitnami LAMP stack via SSH tunnel, as per guide here: https://docs.bitnami.com/virtual-machine/components/phpmyadmin/. I seem to be able to establish the SSH tunnel, and everything looks correct in the PuTTY event log in terms of opening connection for forwarding, etc, but when I try to navigate to http://127.0.0.1:8888/phpmyadmin in a browser as stated in the guide, I am returned the error 'This site can’t be reached. 127.0.0.1 refused to connect.' After I receive this error I check the PuTTY event log and it shows 'forwarded port closed'. Is anyone able to provide me with some troubleshooting steps I can go through or possible solutions for what the problem may be please? Again, if I've not provided enough information please ask and I'll do my best to update what I can.
For background, I am the nearest thing to an IT lead for a GP and this LAMP stack is used for an online system accessed by both patients and staff for a specific health condition. It was independently created by a GP who has since left the practice, but before doing so he imparted onto me what we thought to be enough information/instruction to keep the system "ticking over" until we found a developer to produce a new one (I'm struggling to get in touch with said GP, so currently asking for their help isn't an option). It is a Bitnami LAMP stack created in Microsoft Azure, and has recently developed a SMTP authentication error whenever a patient/staff member needs to request a new or reset an existing password. I am attempting to access phpMyAdmin to check/reconfigure the SMTP server settings in the hopes of rectifying the situation. I do have some systems experience, previously working as a System Analyst/Technician for a hospital, but as I previously stated this area (servers, etc.) are a bit of a blind spot.
Many thanks to anyone willing and able to help.
Bitnami Engineer here,
It seems that the SSH tunnel was not properly created and that's why you can't access phpMyAdmin now. You can try to reconfigure the port forwarding configuration again or you can edit the Apache's configuration to allow remote requests from your IP to the phpMyAdmin application. To do so:
Edit the /opt/bitnami/conf/bitnami/phpmyadmin.conf file and substitute the Require local line with Require ip YOUR_PUBLIC_IP.
If you do not know your public IP, you can access http://myip.bitnami.com to get that information
Restart Apache and access phpMyAdmin using http://MACHINE_IP_ADDRESS/phpmyadmin

Apache2 Not Responding: Bitnami Magento Install (Legacy)

For reasons too insane to even go into, I am attempting to install using the Bitnami Magento 1.9.2.4 image on a fresh Amazon AWS/Lightsail Ubuntu 16.04 instance (2gbs to avoid complaints and be sure I don't run into anything unnecessary).
I think this is really more of an Apache question. After I finish the install (success), I can't get the server to respond via the instance IP address at the default port (8080).
Regarding the old Bitnami Image, you can get (or wget) that Magento 1.9.2.4 image still, it's over here:
wget "https://downloads.bitnami.com/files/stacks/magento/1.9.2.4-3/bitnami-magento-1.9.2.4-3-linux-x64-installer.run"
So for the sake of anyone who's trying to work through the whole process, once you pull the above down to your instance you need to chmod the above file to 755. This assumes you are in the directory with your download:
chmod 755 bitnami-magento-1.9.2.4-3-linux-x64-installer.run
Then run it using it's full path, like:
/home/ubuntu/bitnami-magento-1.9.2.4-3-linux-x64-installer.run
So the install is going to ask a bunch of questions, for anyone keeping track my answers were all yes (ie. yes to Git, PhpMyAdmin, Beetailer... whatever that is).
Then I created an admin user / password etc.
As far as the port I didn't have anything running on 8080 so the install defaulted the port to 8080 with HTTPS on 8443 with MySQL on 3306 (more on ports in a minute).
I think Host/Domain is one of the keys to this problem. When I couldn't get the server to respond I just recreated an instance and tried a different Domain during the install process. I tried: internal AWS IP, External ACTUAL IP, 127.0.0.1
Here's what the Magento 1.9 Domain prompt looks like:
So basically that sort of brings us up to date.
Once I finished the install, like a normal human used to using bitnami as a cloud image I assumed the server would respond at whatever the default path was at the IP address it was running on. Ie:
BASEIPADDRESS:8080/magento
Not the case. When I hit that the server does NOT respond, hence the question. In addition to the above I have also tried the BASEIPADDRESS, and the BASEIPADDRESS:8080
Results checking open ports
So since the server is not responding I figured I would check the ports.
First I checked using netstat:
netstat -lntu
I got back:
Then I realized that netstat is now depreciated... so I went with:
ss -lntu
I got back:
(excuse the images, formatting wouldn't work for text)
To me it looks like 8080 (default) is open in both of those results. So why isn't the server responding at the default location?
#Bitnami Status = OK
Checking the status with:
/home/ubuntu/magento-1.9.2.4-3/ctlscript.sh status
Everything looks good:
apache already running
mysql already running
Memcached not running
Since it says Memcached was not running, I started memcached to see if that was the issue, no it was not.
I can access the instance via SSH and yes I am sure the IP is right. See images above.
I also posted this to the Bitnami community but haven't heard anything over there. Will cross populate as I get ideas.
It looks to me that you configured Magento using the private IP address, so you would not be able to access from your browser. A way to check it is by executing the following command in your machine:
curl -L 127.0.0.1:8080/magento
If that provides output, then the IP is misconfigured, so you would need to reinstall using the proper IP
So this ended up being PRIMARILY due to not running the Bitnami stack installer as root / sudo:
sudo /home/ubuntu/bitnami-magento-1.9.2.4-3-linux-x64-installer.run
Why Install with Sudo on AWS/Lightsail?
So the reason you need to install as sudo has to do with the fact that when run as the normal user (ie. not root) the installer defaults to port 8080 which is NOT open on aws by default. To complicate matters further you may not be able to get things running properly even if you manually swap to port 80 AFTER you run the installer.
To avoid a scenario where port 80 requires root access to utilize I just re-created my instance and ran the installer as root with the above command.
Host Setting
During install I selected the public IP for the "Host" prompt and everything worked as I thought it might (straight out of the box).
Thanks to Javier Salermon who put me on the right track and the devs at Bitnami for cueing me into the fact that 8080 is not open by default.

Unable to Access Webmin 1.780 through browser

I have my website with digitalocean set up to access with ssh and webmin. i went to access it as normal, but suddenly it isn't working. safari shows the connection as refused.
usually it's my-ip:100000 to access but suddenly it's not working. i haven't changed anything so advice appreciated. thanks.
the website itself still works and is powered on.
Sorted this by running a restart through the command line using:
/etc/init.d/restart webmin

Remote port access

I was working on the intranet at work on a virtual machine set up for my project and at some point I have to access it by putting localhost:port number and it works.
Right now I'm home working on it and I can download/upload, use SSH, etc. But I cannot access the same port by putting URL:port number while everything else works.
I'm new to all this so please excuse my ignorance on what could be a very basic subject.<
P.S. the system administrator supposedly gave me full and complete access to the machine, including giving me full firewall permissions. I also have root access via SSH if needed.
THANK YOU!
Try running
ssh -L port:localhost:port remotehost
and then accessing localhost:port as if you were at work.
(n.b. you don't need root access.)

Pushing my Mercurial Repository through HTTP with Apache and Windows

So I have managed it. I can clone mercurial-repositories remotely using HTTP to my Windows Server 2003 machine and the ipaddress from that machine. Although I did deactivate IIS6 and am using Apache 2.2.x now. But not all works right now...darn! Here's the thing:
Cloning goes smooth! But when I want to push my changes to the original repository I get the message "cannot lock static http-repository". On the internet I get to read several explanations that Mercurial wasn't designed to push over HTTP connections. Still, on the Mercurial website there's something about configuring an hgrc file.
There's also the possibilty to configure Apache to host via HTTPS (or SSL). For this you have to load the module enabling OpenSSL and generating keys.
Configuring the hgrc file
Just add "push_ssl = false" under the [web] line. But where to put this file when pushing your changes back?! Because I placed it in the root of the server, in the ".hg" directory, nothing works.
Using SSL/HTTPS with Apache
When I try to access 'https://myipaddress' it fails, displaying a dutch message which would mean something like "server taking too long to respond". Trying to push also gives me a dutch error message which means about the same. It can not connect to my server via https although I followed the steps exactly at this blog.
I don't care which of the above solutions will work for me. Turns out none of them work so far. So please, can anyone help me with one of the solutions above? Pick the easiest! Help will be greatly appreciated, not only from me.
Summary
-Windows Server 2003
-Apache 2.2 with OpenSSL
-Mercurial 1.8.2
-I can clone, but not push!
Thank you!
Maarten Baar(s)
It seems like you might have apache configured incorrectly for getting it to do what you want. Based on your question it sounds like you have a path (maybe the root of the server) pointing to the repository you want to serve.
Mercurial comes with a script for this exact purpose, in the latest version it is hgweb.cgi. There are reasonably good instructions for setting it up on the mercurial site. It should allow both cloning and pushing. You will need the push_ssl=false if you will not be configuring https and also an allow_push line which will let certain users, or all (*) push to the repository. But all that should be part of the setup docs.