L. Arnold's picture

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: 
L. Arnold's picture

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!

 

L. Arnold's picture

Jeremy Davis's picture

My initial guess was that there is some Linode level firewall (like Amazon have their "security groups"). But looking at your netstat output it seems that's not the problem. I would guess that it's webmin listening on port 10000 (that's it's non-TKL default).

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:

service webmin status
service shellinabox status
service stunnel4 status

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".

L. Arnold's picture

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.

L. Arnold's picture

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

 

L. Arnold's picture

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)

 

Jeremy Davis's picture

Whilst stunnel runs in a non-privileged account it doesn't have a password so that shouldn't be the issue. If you look in /etc/stunnel/stunnel.conf you should see that it has a user called "stunnel" and that the PID should be being created within the stunnel user chroot. It is really weird that this is an issue... I'd probably check that the user exists for starters; then double check where it's home is and make sure that it owns it's home directory. I'm not 100% but I'd assume that it's home is where the chroot is running...
L. Arnold's picture

It seems that setting only applies to the main HD.  Nothing more specific than that.

How do I test?  (thpe Chroot?)

thanks.

L. Arnold's picture

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?)

L. Arnold's picture

I will test a bit more tommorrow.  Odoo via XEN is working ok w/th these ports.

 

L. Arnold's picture

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.

Jeremy Davis's picture

If you haven't already, I suggest that you configure pre-seeding; it is covered quite well on the (old) Xen announcement blog post. Then you can set your passwords as you desire...
L. Arnold's picture

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)

Jeremy Davis's picture

That's because Xen is headless! :) FWIW Amazon use Xen backend too; although there environment is quite diffeent to a 'simple' Xen set up.

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).

L. Arnold's picture

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.

L. Arnold's picture

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.

Jeremy Davis's picture

But some VPS providers support usage of third party ISOs. Perhaps that's an option? Even if they don't obviously offer that; then maybe it's worth asking their support desk?
L. Arnold's picture

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.

L. Arnold's picture

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.

 

 

 

Jeremy Davis's picture

Generally though preseeding should allow you to set all your passwords and they should just work. Perhaps Linode have it set up different?
L. Arnold's picture

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)

root@magento ~# systemctl status stunnel4
* stunnel4.service - LSB: Start or stop stunnel 4.x (SSL tunnel for network daemons)
Loaded: loaded (/etc/init.d/stunnel4)
Active: active (exited) since Tue 2015-12-01 04:46:36 UTC; 8min ago
Process: 2989 ExecStart=/etc/init.d/stunnel4 start (code=exited, status=0/SUCCESS)
 
Dec 01 04:46:36 magento stunnel[3083]: LOG5[3083]: Compiled/running with Op...15
Dec 01 04:46:36 magento stunnel[3083]: LOG5[3083]: Threading:PTHREAD Socket...AP
Dec 01 04:46:36 magento stunnel[3083]: LOG5[3083]: Reading configuration fr...nf
Dec 01 04:46:36 magento stunnel[3083]: LOG5[3083]: FIPS mode disabled
Dec 01 04:46:36 magento stunnel[3083]: LOG5[3083]: Configuration successful
Dec 01 04:46:36 magento stunnel4[2989]: Starting SSL tunnels: [Started: /etc....
Dec 01 04:46:36 magento stunnel[3099]: LOG3[3099]: Cannot create pid file /...id
Dec 01 04:46:36 magento stunnel[3099]: LOG3[3099]: create: Permission denie...3)
Dec 01 04:46:36 magento systemd[1]: Started LSB: Start or stop stunnel 4.x ...).
Dec 01 04:53:06 magento systemd[1]: Started LSB: Start or stop stunnel 4.x ...).
Hint: Some lines were ellipsized, use -l to show in full.
L. Arnold's picture

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.

Jeremy Davis's picture

You may need to tweak permissions of the directory where it's trying to save it's PID file. If you look in /etc/init.d/stunnel4 you should see where it's storing it's PID file; then check on the permissions using 'ls -l /path/to/pid'.
L. Arnold's picture

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.

  • Get Linode to convert your system from KVM to XEN  (perhaps works in KVM)
    • (after one conversion, you can clone the build over and over and seemingly get XEN)
  • Create a Drive for the Linode  (sdc)
  • Boot the Linode
  • Mount the drive with
  • cd /mnt
  • mkdir /sdc
  • cd /
  • mount /dev/sdc /mnt/sdc 
  • Then via FTP
  • upload the TKL XEN build to /mnt/sda
  • Then via SSH
    • 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

      • ​wait
      • 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.

L. Arnold's picture

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.

L. Arnold's picture

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.

Jeremy Davis's picture

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...)

L. Arnold's picture

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.

Jeremy Davis's picture

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:

ip link show
nmcli device status
nmcli connection show
netstat -i
ifconfig -a

If you can't decode what the results mean, please feel free to post back with the output they give and I can assist.

L. Arnold's picture

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.

L. Arnold's picture

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
 

Jeremy Davis's picture

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:

# UNCONFIGURED INTERFACES
# remove the above line if you edit this file

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

#auto eth1
#iface eth1 inet dhcp

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:

# remove the above line if you edit this file

auto lo
iface lo inet loopback

auto enp0s3
iface enp0s3 inet dhcp

#auto eth1
#iface eth1 inet dhcp

Then try restarting networking, I think that this should do the trick:

service networking restart

If that still doesn't get it going, you can try manually starting it:

ifup enp0s3

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:

# default network interface to display in usage
#default_nic eth0

# command to get public ipaddress to display in usage
#publicip_cmd curl -s https://api.ipify.org
#publicip_cmd ec2metadata --public-ipv4
networking true

Uncomment the 'defulat_nic' line and change the interface. I.e. after editing:

# default network interface to display in usage
default_nic enp0s3

# command to get public ipaddress to display in usage
#publicip_cmd curl -s https://api.ipify.org
#publicip_cmd ec2metadata --public-ipv4
networking true

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.

L. Arnold's picture

~# 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
 

Jeremy Davis's picture

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').

L. Arnold's picture

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.

 

L. Arnold's picture

 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 >

Jeremy Davis's picture

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).

L. Arnold's picture

Thanks Jeremy

I'll give it a try.  Got a TKLDEV 15 to run (separate system).  Wahoo.

 

L. Arnold's picture

Also,  what If I "renamed" it to ETH0?

Jeremy Davis's picture

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.

Add new comment