You are here
L. Arnold - Sun, 2015/11/22 - 21:11
I have gotten 2 x Xen Images to build on Linode (www.linode.com). (TKL Jessie 14.0)
For some reason I am not getting either Webmin or Webshell to load.
I am able to access SSH via port 22 however.
I am also able to run the default Webservers on each (Magento and Odoo).
Any clues on enabling Webshell and Webmin?
thanks in advance.
Forum:
IPTABLES Perhaps?
Just got this info:
Guessing it is rather something with the way Inithooks are completing but not sure.
Hi there,
It looks like your Linode is refusing connections on that port:
$ telnet 198.58.101.10 12321
Trying 198.58.101.10...
telnet: connect to address 198.58.101.10: Connection refused
telnet: Unable to connect to remote host
I would recommend reviewing your iptables rules to ensure that you are not blocking traffic to that port. You may view your current rules with the following command:
sudo iptables-save
If you have any other questions or concerns, please don't hesitate to ask!
Netstat Screenshot
Looks like there is something not quite right...
Another thought is perhaps stunnel isn't running. For v14.0 both Webmin & Webshell are hidden behind stunnel (new TKL default). So first thing I would do is make sure that Webmin, Webshell and Stunnel are all running:
If any of them report as "active(exited)" it means that there is something wrong that is stopping them from runnign and you should probably check logs to see what the issue might be. If any of them aren't running then you could try substituting "start" for "status".
Looks like permissions need to be set. Still No show. "init" ?
seems an issue with the Root Password
I can change the Root Password in Linode but it likely is not changing the password for these services.
I will reset to default to test, then come back around.
Linode won't let me set it to the default (too simple)
What would be a way to set the Root Password on XEN so that the services are also updated?
Also, best tool for Conf File Editing in Shell? (how to exit and save also?) So reliant on webmin it shows.
going to try
vim (file name)
then (escape)
:q
pretty sure the issue is stunnel
The .pid file is not being created for stunnel...
Petrhaps a permissions issue?
I am going to type passwd and see what happens.
(Acted like it changed the password but it didn't. Reboot brougth the password to the more complicated one I set before)
If you can log in as root then you should be good.
Linode does have a "setting" about chroot
It seems that setting only applies to the main HD. Nothing more specific than that.
How do I test? (thpe Chroot?)
thanks.
What might I do to get it going manually
service stunnel4 start
service webmin start
service shellinabox start
(do not return visible errors).. but still can't get into the services.
Will check the logs nexe.
-------
If I type:
users
I get :
root root
(why twice? why no others?)
Turns out Odoo is functioning properly.. (only Magento issue)
I will test a bit more tommorrow. Odoo via XEN is working ok w/th these ports.
MagentXEN Build - Hang up seems to be on the Default Password
I've done a new build. Gone pretty well but I have another system taking a 1/2 built ISO in which seems better. Anyway I thought I would try XEN again.
Alon's comment above says "default" PW is turnkey.. dug a little deeper and it seems to being set to a Random Value.
I can "reset it" and sort of get control via glish and SSH. However It is not effecting
This seems to only be an issue on my Magento XEN build. Odoo XEN build is working OK.
Perhaps should post to tracker.
Have you tried preseeding?
Preseeding and Interactive...
So I have had 2 good builds with Odoo then a bad one. Seems to be an issue with who/how the root password is set and taken by TKL Xen. I will look at the preseeding...
The other idea is how I can convert the build into a "Interactive" build. XEN is thinking it is Headless. I can get access via different paths to SSH in all this.
Right now the Headless build has dropped me onto the Root Login and I can't get in to finish the build without resetting the password via Linode....
I am at the turnkeyinit.fence right now.
I don't think the system is taking any of my potential root passwords however. Its not.
So basically, I need to issue a Linode Shutdown Command.
Use Linode to Change the Root Password.
Reboot (1/2 way through the install it seems).. I am guessing I will not have access after this to the stunnel. Something is setting the STUNNEL Password before I change the password in Linode so I can access things.
The Full Interactive Script from this Zen Build Might Help to get past the Console and reset the stunnel passwordl
TMI I know.
(I just logged in with the New Password and GOT "Could not change the directory to root. Permission Denied.". Then it proceeded to the App Passwords Setting module (not including the Root Password Setting)
Xen builds are headless by design!
FYI the inithook which sets the root password is not used in some builds where the root password is set externally (e.g. Proxmox). I'm not that familiar with Xen (at least not in practice) so I don't recall how that works...
Also FYI my suspicion is that you are not root when you logged in. The "Could not change the directory to root. Permission Denied." message commonly occurs if you are in "/root" (i.e. root's home directory) but are not the root user (e.g sudo in as a non root user).
Deleted 29preseed for now
It seems there may be an issue in that there is also
29sudoadmin in the same folder.
Would indicate that the numbering might want to jump (should 29sudoadmin be before 29preseed)
in usr/lib/inithooks/firstboot.d/ ?
Lets see what happens with this Buiild first.
---------
Nope.. Get a Dialog to enter a New Root Password, but it is all messy and can't see it in SSH.
Trying to get it to show in Getty but things are not showing up there yet... Argh.
Lets try one more time. Perhaps If I just run it in Getty.. Or Perhaps change the "sudo admin" order...
Stabbing at all this mostly.
---------
yes there is somethign else in the Headless.
"directing output to log/var\inithooks.log" in Getty which is the only reasonable place to run the full set of password settings.
Will throw Preseed back and try another route.
-------
Probably best to use a rsync command on a Install Restart. Worked yesterday except my filesystem was too short (I used DD yesterday and had a very short set of Disks)..
Seemed a good direction and there should be a way to expand the FileSystem post transfer or have the DD simply work minus GRUB etc.
Wacked through but not pretty.
Guessing I need to Preset AGAIN the root password and use the preseed process.
After getting Odoo and Postgres and Confconsole running still an issue with Stunnel and 12321 and 12322 on this Odoo build.
Since I got it to work yesterday I will assume its doable but will stop pinging for for a bit.
There seems to be different ways to skin this cat.
Nice that Linode does have the Getty capability in the KVM servers (not XEN). Implies the Normal ISO or VMDK builds are likely best to use.
I'm not sure if Linode support it or not
Best to get it to the Hub (hopefully soon)
Interesting project. I've learned a lot. What does work is migrating a "built" system in. I need to learn about resizing the File Area (after a small DD) or learning about rsync some more.
Linode would do well to not have it be so difficult. Seems they are not really iterested though. The prices seem fair and performance is quite zippy.
Linode/ TKL XEN some Sort of CHROOT issue
So If I set the Root Password and have a XEN build set to a new boot disk what happens is:
Boot: Old Password gets in..
Takes a While to Actually "build out" ...
The TurnKeyInit.Fence Shows up. MySQL, Magento Admin (and updates etc set).
At the End Root Password does not work in AJAX Shell (still can't log in to Webmin or Webshell)
I then issue a
Reboot Command Given In Linode:
AJAX Linode Shell does work now with old Password.
...
My impression is that a second CHROOT Mode is entered and some random password set (as evidenced by not being able to login to root at end of turnkey-init-fence.
Reboot abandons that Mode and original password works
Neither Root is allowing STUNNEL4 to operate thus Webmin and Webshell not working.
Magento is working
Ajax shell is working in Linode
Glish is not working in Linode
(Perhaps Writing over a Debian Install - configured as a boot, then making it a "second" disk, overwriting it with XEN)... So strange it worked once with Odoo.
I don't know enough about how Linode is set up
Strange Permission Issue for STunnel on Magento
Everything else seems to be running:
Take a Look at This Screen Shot showing Magento vs Odoo on stunnel4 Service
Looks Like I have a "Group" issue perhaps.
Shows STUNNEL running in Odoo and Not in Magento
-----
I can operate in SSH so need to check for the USER and the Folder... Tried to create an "apache" hook but that is not working so far. Nor are listening to ports 10000 or 4200 (webmin/webshell)
Pic above is Wide (showing functioning window to right)
Not seeing an easy way to expand the pic here.. but to the right is the Odoo Ap which is functioning on Linode. Not clear why the Magento build is not functioning properly.
(Will Load a Full System post install next)
Below is Odoo STunnel running in Linode.
It looks like it doesn't have permissions to store it's PID
Learned a trick. (try again, pay attention, things work)
Odoo was working. Magento not.
Finally tried Joomla, and it was working. Therefore had to try Magento one more time.
My experience to get running was the following.
if needed: apt-get install bzip2
bzip2 -dvf turnkey*.bz2
tar -xvf turnkey*.tar
rm turnkey*.tar
Shutdown the Linode
Create a New Boot Script
Have the New Drive be the Boot Drive
Save
Assign New Root Password from Linode Restore Dialog for the NEW DRIVE
Boot
do not login
let Turnkey get to work (forgot the term for this)
Finally when it appears that the XEN building is done
Firstboot InitHooks may appear
if they don't, then "shut down"
Go to "restore" and once again Reassign the Root Password from Linode
Reboot
Wait the 1 minute 30 Seconds for the Slow boot on one drive (seems fixable)
First Boot Inithooks (type away)
When Complete
Type ConfConsole to verify
or
Type turnkey-init to get a reset on your passwords (root is not reset)
Should All be working Now (i've done Odoo, Joomla and Magento this way now)
I will try KVM versions of this. I have also been able to do "rsync" and "dd" versions to also work copying VMWare installs. Expect similar can be done with AWS but have not tried and not really needed there.
Seems to work on KVM mode (default) as well
Even though you can have XEN implemented (old build) at Linode, it seems the process above also works on the Linode KVM build as well.
Basic variable from the TKL ISO is that Linode process controls the Root User rather than setting it in TKL Firstboot Inithooks --------- "turnkey-init"
All good. Just documenting.
XEN Networkin not passing in TKL 15 Magento 2.2 (new build)g
Just tested and built a version 1.9x Magento off of TKL 14 from XEN Images
Trying now to build 2.2x Magento off of TKL 15 from XEN.
Networking is not passing through unfortunately. Prior Magento was calling Networking Port ETH1. Now none of the ports that show up in ConfConsole seem to be able to take the Linode Networking stream.
As noted, this approach did work in TKL 14 Magento 1.9x, and does still. I did several tests around this today.
I will try Odoo next to see if the issue is with the Magento App or more with the Stretch XEN builds.
argh.
Hi Landis
Sorry to hear of your troubles getting it working. I don't know enough about Linode's Xen setup to give any real advice, but FTR they "just work" on vanilla Xen (tested using Xen from Debian Stretch repos). It's also worth noting that AWS also used (a somewhat customised) Xen as the hypervisor layer (and obviously they work too).
One thing that comes to mind is that the v15.x Xen images moved to being aimed at an HVM setup (although should still work with the old PV setup). If you're not sure on the difference, please see this.
Also, one other thing re networking; in Debian Stretch (basis of v15.x) by default network interfaces use a new naming convention, known as "Predictable Network Interface Names". Although we override that to provide the old legacy ethX naming convention. Perhaps there is something within Linode (especially if they are using PV?!) that somehow overrides that and the interfaces are named something else? (I'm only guessing though...)
I think the Naming is the issue
TKL XEN 14 was bringing up the networking as ETH0
When I get into Confconsole successfully in TKL XEN 15 there is no ETH(anything) named.
I am trying a XEN 14 on Django now.
I want try to decompress some other builds to see where that gets me so that I can use TKL 15. This all takes a while.
I really want to stick with Linode. Perhaps we could build some StackScripts for Linode?? There are various routes on this and I know we can get them to work.
Perhaps try seeing what interfaces it does have?
TBH, if one appliance isn't working, I doubt any of the others will. My suspicion is that whatever the issue is, it is common to all appliances. I say that because all the network configuration stuff (such as confconsole) is inherited from Core.
Assuming that you can log in via a terminal, here are some commands which might be useful in understanding what interfaces your Linode server has:
If you can't decode what the results mean, please feel free to post back with the output they give and I can assist.
Thanks for the leads Jeremy,
Thanks for the leads Jeremy, I will test.
I need to update something so that I get notification of replies without getting a flood.
Back on the TKL wagon though. Psyched w/ some work I have done recently.
ip link show - brings in Active SSH session
Some of the commands:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAUL0
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group 0
link/ether 3a:9b:39:8d:8a:a0 brd ff:ff:ff:ff:ff:ff
3: enp0s3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT gr0
link/ether f2:3c:91:14:0f:cf brd ff:ff:ff:ff:ff:ff
4: teql0: <NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qle0
link/void
5: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group defaul0
link/ipip 0.0.0.0 brd 0.0.0.0
6: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN mode DEFAULT group default0
link/gre 0.0.0.0 brd 0.0.0.0
7: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN mode DEFA0
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
8: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFA0
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
9: ip_vti0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group defa0
link/ipip 0.0.0.0 brd 0.0.0.0
10: ip6_vti0@NONE: <NOARP> mtu 1364 qdisc noop state DOWN mode DEFAULT group de0
link/tunnel6 :: brd ::
11: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group defaul0
link/sit 0.0.0.0 brd 0.0.0.0
12: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN mode DEFAULT group def0
link/tunnel6 :: brd ::
13: ip6gre0@NONE: <NOARP> mtu 1448 qdisc noop state DOWN mode DEFAULT group def0
link/gre6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd 00:00:00:00:00
Judging from this output, it looks like enp0s3 is the interface
Judging from this output, it looks like enp0s3 is the interface that you'll want to configure. You could try configuring that interface by adjusting the network config file. The file you'll want to edit is /etc/networking/interfaces. By default it should look like this:
To enable the enp0s3 interface, within that file swap where it says 'eth0' to 'enp0s3'. Also, delete the line that says 'UNCONFIGURED INTERFACES'. So that it looks like this:
Then try restarting networking, I think that this should do the trick:
If that still doesn't get it going, you can try manually starting it:
Assuming that that then works, you'll likely want to adjust confconsole to use that interface too. To do that, edit the config file (/etc) and change the interface to enp0s3. I.e. the default file:
Uncomment the 'defulat_nic' line and change the interface. I.e. after editing:
Although I suspect that setting a static IP might break networking, so you are probably best to also disable the networking component of the build (if it's not already disabled). That's done by setting "networking false" (on the last line).
Hope that helps.
More command results
~# nmcli device status
-bash: nmcli: command not found
~# nmcli connection show
-bash: nmcli: command not found
~# netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
lo 65536 1152 0 0 0 1152 0 0 0 LRU
nmcli is not installed by default - sorry my bad...
Apologies on that. It's the cli tool for working with Network Manager. I forgot that Network Manager isn't installed in TurnKey by default. You could install it, but I wouldn't bother myself. You won't be able to use it until you have networking working ok, but then you won't need it anymore! :)
Your netstat line shows that only the loopback device is active. That's not what we want... We also want an ethernet device enabled (as noted above, I'm pretty sure that will be 'enp0s3').
Having trouble controlling the output in glish
basically I get too much info with "ifconfig -a" (scrolls off my screen and I can't get it back)
I can get some info still:
~# netstat -inet
Kernel Interface table
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 2880 bytes 213120 (208.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2880 bytes 213120 (208.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
~# ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 3328 bytes 246272 (240.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3328 bytes 246272 (240.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
---------
There are a whole bunch of ports. Seems it would be good to redefine a eth0 (zero) port.
~# ifconfig eth0
eth0: error fetching interface information: Device not found
Anyway, some info so far.
These are the PORTS that TKL seems to have available:
Choose network adapter to configure │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ dummy0 not configured │ │
│ │ enp0s3 not configured │ │
│ │ erspan0 not configured │ │
│ │ gre0 not configured │ │
│ │ gretap0 not configured │ │
│ │ ip6_vti0 not configured │ │
│ │ ip6gre0 not configured │ │
│ │ ip6tnl0 not configured │ │
│ │ ip_vti0 not configured │ │
│ │ sit0 not configured │ │
│ │ teql0 not configured │ │
│ │ │ │
│ └──────────────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────────┤
│ <Select> < Back >
As noted above, I reckon 'enp0s3'
I'm not 100% sure and am only guessing, but I reckon that enp0s3 is the interface you'll want to try to configure (as posted in more detail above).
Thanks Jeremy
Thanks Jeremy
I'll give it a try. Got a TKLDEV 15 to run (separate system). Wahoo.
Also, what If I "renamed" it
Also, what If I "renamed" it to ETH0?
It should already be being renamed...
In v15.x we are already "renaming" the new Predictable Network Interface Names (using default naming convention - i.e. eth0). We do that via passing the setting "net.ifnames=0" to the kernel at boot time (via grub - see the 'GRUB_CMDLINE_LINUX=' line in /etc/default/grub).
But for whatever reason, those changes aren't being applied for some reason on Linode. My guess is that they provide some custom kernel so the options are being overwritten at boot time. TBH, I think that you're best to work with what you have. But please feel free to have a poke around. Let me know if you have any luck.
Agree that this is likely a series of Grub and Format issues
My goal is to boot from one of the Containers (v 15) as I could earlier (v 14) XEN then. Can build "Direct Disk" installs from ISO but cannot then use Linode to resize drives, make snapshots, take effective backups etc. Moving from Direct Disk to EXT4 should work, but when I do I either lose All Grub, or the ability to use Networking effectively
Am thinking I want to work on a Build Task for a Linode usable build. It would be ideal if it would just take a TKL Container and I would move forward.
One issue I am percieving is that Linode seems to be using KVM and TKL ISO is building LVM and would be best to just have TKL ISO build Linode understandable KVM image blocks.
I am going to see if I can build from ISO directly to their EXT4 block format. Doubtful.
(Just tried that in fact. I could set it up as EXT4 and assign it to the build, but in turn, TKL put LVM and Partitions to it. Now Linode cannot shrink or expand it as would be normal working possibility "Error determining filesystem blocksize ")..
Ideally I want to bypass partitioning. Likely a way through TKLDEV. I cannot get that to show up as an option installing from ISO.
I don't know enough about Linode to give much more advice.
A few points here:
As noted above; the term "container" has a pretty specific meaning. In the context of Linux, containers generally refer to an OS (or a partial OS) which leverages the kernel (and perhaps other components) of the host OS. In recent years, some improvements have been made, but AFAIK they're still not completely isolated. The 2 most popular types of container are "OS containers" i.e. LXC/LXD and "app containers". So called "app containers" generally don't include a full OS, only the dependencies required for the particular application they include. The most popular of these second type is Docker, although there are others such as rkt. Actually SystemD (the default init system in TurnKey since v14.0) actually includes a container platform called nspawn OOTB. Nspawn can run "OS containers" or "app containers", although it's not really recommended (at least for now) as a platform for running anything other than local applications/containers.
A "VM" runs as a complete, and generally isolated OS. Xen and KVM (as well as many others) are considered "hypervisors" and run "VMs" - not "containers". A VM can support any OS as a guest (e.g. you can run a Windows guest VM on a Linux host), whereas a container can only run a guest of the same type (i.e. a Linux container can only run on a Linux guest). Don't be confused by Windows marketing which suggests that (Linux based) Docker containers can now run on Windows - they can, but only because there is a Linux VM running behind the scenes.
Sorry for the rantish paragraphs, but I wanted to make sure that we are on the same page! :) But back to your points...
FWIW all of our builds (and all of the existing buildtasks) start with an ISO and convert that the appropriate format. So a "bt-linode" buildtask would ideally do the same thing - convert an ISO to a Linode VM.
OTOH, if you can get the TurnKey LXC appliance running on Linode (Xen or KVM), then you could run your TurnKey (or other LXC) containers as guests on the LXC host.
KVM is a hypervisor, LVM is a way of managing disks. I personally use KVM all the time and it works fine with (or without) LVM. In fact KVM is completely unaware that I am using LVM on my (virtual) disks. I can also expand the disks when necessary (although I still need to expand the volume group, logical volume and filesystem). It's also worth noting that if you don't wish to use LVM you can skip that at install. (IIRC when it asks about installing it's the second option down, the first (with LVM) is the default).
It's possibly also worth noting that our VMDK build includes a VMDK OS image. KVM supports that OOTB in my experience (although it does prefer to use it's native QCOW2 image format). Also, it's possible that Linode don't support VMDK disk images. But FWIW on a Linux machine (e.g. TKLDev) with qemu installed it's easy enough to convert a vmdk image to a qcow2 one:
Solved Networking Access
Just closing this thread:
in LISH/Weblish/GLish of Linode
Issue this command to disable Predictable Network Interface Names
then, in TKL 15.5 anyway, go to
/etc/network/
dir
vim interfaces
be sure you have:
It seems I have "default" set to either eth0 or eth1, but anyway it is working
I went ahead and rebooted - all good
I can see I should edit the ConfConsole Interfaces Comment is there from Jeremy above on how to edit that, but I am not finding the file in v TKL 15.5 Joomla build.
All systems generally go. I will work next on setting my TKLDEV to mimic this.
Thanks in advance.
The long Threads do bring a lot of light on to the systems even though the variables are great within them.
This was indeed a Linode KVM issue somehow related to their KVM implementation that they reference to ARCH and (perhaps) CentOS build issues with Predictable Names.
see this link: https://www.linode.com/docs/platform/disk-images/kvm-reference/
Add new comment