Installation disaster
-
- Beiträge: 75
- Registriert: Mo 17. Sep 2018, 20:25
Re: Installation disaster
Hello gd7s9sjddh,
as before, I completely agree with you and confirm your statements.
The script is a bit unusual in some places.
Please excuse me for forgetting to give you a hint about possible mysql errors.
As for the updates, I can reassure you a bit. Up to now the updates on my PC ran error free via the GUI. The warnings regarding firewall and so on, however, come back. But a changed root password doesn't cause any problems.
A little tip to you, you can also freely choose the IP address of the server and not stick to the somewhat nonsensical suggestions of the manual. If you want to run the server in server mode, you have to change a configuration file. If you have not chosen a xxx.xxx.xxx.2yy ipv4 address. If you want I can tell you the name of the file.
From a security point of view, the changes made by the installation script are really not recommended. I think most clubs don't care much. But the system was too insecure for me. Accordingly, I have severely limited the network traffic and use very restrictive firewall settings.
It is also interesting that the installation script makes further system changes that are completely unnecessary for the operation of the software. For example, the default theme of the login manager is overwritten.
Should you have any further questions or encounter any other problems, I will be happy to help you as much as I can.
Many greetings,
Maximilian
as before, I completely agree with you and confirm your statements.
The script is a bit unusual in some places.
Please excuse me for forgetting to give you a hint about possible mysql errors.
As for the updates, I can reassure you a bit. Up to now the updates on my PC ran error free via the GUI. The warnings regarding firewall and so on, however, come back. But a changed root password doesn't cause any problems.
A little tip to you, you can also freely choose the IP address of the server and not stick to the somewhat nonsensical suggestions of the manual. If you want to run the server in server mode, you have to change a configuration file. If you have not chosen a xxx.xxx.xxx.2yy ipv4 address. If you want I can tell you the name of the file.
From a security point of view, the changes made by the installation script are really not recommended. I think most clubs don't care much. But the system was too insecure for me. Accordingly, I have severely limited the network traffic and use very restrictive firewall settings.
It is also interesting that the installation script makes further system changes that are completely unnecessary for the operation of the software. For example, the default theme of the login manager is overwritten.
Should you have any further questions or encounter any other problems, I will be happy to help you as much as I can.
Many greetings,
Maximilian
-
- Beiträge: 12
- Registriert: So 3. Nov 2019, 00:02
- Verein/Verband: SVI
Re: Installation disaster
Wow Maximilian, many thanks for the insight and the great tips.
I think I lost enough time. It is time for Meyton to lose their time fixing their mess.
I have a properly working MySQL but the magic script fail to connect and don't provide any hint at all.
I ended up finding the /etc/meyton folder but I see that the magic of their automation fails in many places.
Would you mind telling my which version of MySQL is running on your working system?
I think I lost enough time. It is time for Meyton to lose their time fixing their mess.
I have a properly working MySQL but the magic script fail to connect and don't provide any hint at all.
I ended up finding the /etc/meyton folder but I see that the magic of their automation fails in many places.
Would you mind telling my which version of MySQL is running on your working system?
-
- Beiträge: 75
- Registriert: Mo 17. Sep 2018, 20:25
Re: Installation disaster
Hello gd7s9sjddh,
I just checked. On one of my systems does not run mysql. Instead it runs mariadb in version 10.2.22-lp150.2.9.1
It is no longer the most current version. I should update this.
Try to install the Meyton software without mariadb or mysql version installed. The shootmaster software installs a version as far as I know. But I can't tell you exactly which version.
At my first installation I am half desperate and have tested different variants and versions on installed packages. unfortunately I can't remember exactly which combination brought the success. Try it without mysql and mariadb version installed.
Please keep me informed if you've made any progress.
Many greetings,
Maximilian
I just checked. On one of my systems does not run mysql. Instead it runs mariadb in version 10.2.22-lp150.2.9.1
It is no longer the most current version. I should update this.
Try to install the Meyton software without mariadb or mysql version installed. The shootmaster software installs a version as far as I know. But I can't tell you exactly which version.
At my first installation I am half desperate and have tested different variants and versions on installed packages. unfortunately I can't remember exactly which combination brought the success. Try it without mysql and mariadb version installed.
Please keep me informed if you've made any progress.
Many greetings,
Maximilian
-
- Beiträge: 12
- Registriert: So 3. Nov 2019, 00:02
- Verein/Verband: SVI
Re: Installation disaster
Currently, I have an half working version.
I did manage to get ShootMaster to partly work but some function such as upgrading the DB fails at some point with a message such as "it did not work" without any further detail.
I initially wanted to use MariaDB but gave up due to issues that are probably NOT Meyton's fault.
When you install MariaDB, an ALIAS mysql.service is created so you can use MariaDB just as you would with MySQL.
This fails however at some point because the alias is not followed. There is an issue on Github about that.
The easiest solution IMO would be for Meyton to adapt the scripts to specifically support MariaDB and no longer MySQL.
That would be much easier for the users to install and update and for Meyton, this is a single string to replace.
MySQL 8 works HOWEVER:
- many of the commands Meyton scripted no longer works in MySQL8 or you at least need extra commands. For instance, you no longer can create an account and grant right just with one grant command.Now the script would have to do a create first.
- it comes with a new auth protocol that Meyton does not support (sha2 I think), making SM unwilling to connect
There is a way to set back account to an old password and as soon as you do that, SM shows that the connection was established.
I can paste the command here once everything works but I don't want to confuse people until my solution is fully working.
I did manage to get ShootMaster to partly work but some function such as upgrading the DB fails at some point with a message such as "it did not work" without any further detail.
I initially wanted to use MariaDB but gave up due to issues that are probably NOT Meyton's fault.
When you install MariaDB, an ALIAS mysql.service is created so you can use MariaDB just as you would with MySQL.
This fails however at some point because the alias is not followed. There is an issue on Github about that.
The easiest solution IMO would be for Meyton to adapt the scripts to specifically support MariaDB and no longer MySQL.
That would be much easier for the users to install and update and for Meyton, this is a single string to replace.
MySQL 8 works HOWEVER:
- many of the commands Meyton scripted no longer works in MySQL8 or you at least need extra commands. For instance, you no longer can create an account and grant right just with one grant command.Now the script would have to do a create first.
- it comes with a new auth protocol that Meyton does not support (sha2 I think), making SM unwilling to connect
There is a way to set back account to an old password and as soon as you do that, SM shows that the connection was established.
I can paste the command here once everything works but I don't want to confuse people until my solution is fully working.
-
- Beiträge: 75
- Registriert: Mo 17. Sep 2018, 20:25
Re: Installation disaster
Hello gd7s9sjddh,
thank you very much for your detailed feedback.
I hope Meyton will take up the topic MariaDB and incorporate it into the installation script.
Many greetings,
Maximilian
thank you very much for your detailed feedback.
I hope Meyton will take up the topic MariaDB and incorporate it into the installation script.
Many greetings,
Maximilian
-
- Administrator
- Beiträge: 769
- Registriert: Mi 9. Mär 2016, 16:14
Re: Installation disaster
We are sorry that you have problems with the installation process of our software. Because most of our users don't have any linux knowledge at all, we try to automate the process as much as possible. This may confuse people which are familiar to linux.
If you follow our instructions exactly, there should be no problems installing the software. Any deviation from the manual can cause problems when setting up the system.
https://www.meyton.info/uploads/media/E ... p_15.1.pdf
https://www.meyton.info/uploads/media/E ... 4.9.6a.pdf
If you follow our instructions exactly, there should be no problems installing the software. Any deviation from the manual can cause problems when setting up the system.
https://www.meyton.info/uploads/media/E ... p_15.1.pdf
https://www.meyton.info/uploads/media/E ... 4.9.6a.pdf
-
- Administrator
- Beiträge: 769
- Registriert: Mi 9. Mär 2016, 16:14
Re: Installation disaster
To clarify some wrong assuptions made here:
- the installation does work even if the firewall is not installed -> you get an error message but the installation continues anyway
- while the installation is running additional 32bit libs are installed -> if the libs are already installed you get a warning, but the installation process continues anyway
- in the installation manual there in nowhere said that the user should use "sudo" -> the installation has to run with user "root" logged in
- we are using the database which comes with the standard installation of openSUSE -> this is actually MariaDB and not MySQL. using a different versoin is not supported.
-
- Beiträge: 75
- Registriert: Mo 17. Sep 2018, 20:25
Re: Installation disaster
Morning Roman,[MEYTON] RG hat geschrieben: ↑Mo 2. Dez 2019, 13:17To clarify some wrong assuptions made here:
Generally the installation process and the corresponding scripts are tested with the default installation procedure described in the manual.
- the installation does work even if the firewall is not installed -> you get an error message but the installation continues anyway
- while the installation is running additional 32bit libs are installed -> if the libs are already installed you get a warning, but the installation process continues anyway
- in the installation manual there in nowhere said that the user should use "sudo" -> the installation has to run with user "root" logged in
- we are using the database which comes with the standard installation of openSUSE -> this is actually MariaDB and not MySQL. using a different versoin is not supported.
regardless of the confusing error messages, I still wonder why a software without good reason changes the root password to a default value.
This is not really acceptable from a security point of view. Every user have to change the password afterwards.
It also seems unnecessary to create a user Otto with an insecure password. Is it not possible to use the existing user account without creating a user Otto? The creation of the user Meyton as a necessary system user is not the problem, but the user Otto is completely superfluous.
As much as I am a fan of Meyton software and products, I am disappointed about these unnecessary security gaps. If one were to find such serious system interventions in another commercial software, it would probably result in a CVE entry.
Is it at least possible to remove the user Otto after the installation? There are no problems with the firewall, the root password and using a different user account. Is that the same after deleting the user Otto?
Thank you for your feedback and help.
Many greetings,
Maximilian
-
- Beiträge: 12
- Registriert: So 3. Nov 2019, 00:02
- Verein/Verband: SVI
Re: Installation disaster
A year has past and I finally got to talk to someone working at Meyton. For a year, we have been left with an half-working system.
I totally agree with Maximillian's previous statement: The Meyton software is great and many of the technical choices are great. However, the way security and the installation is handled is far from glorious. I am sure the motivation of Meyton is good, but the solutions are bad (for the installation script).
I wont provide details here but it would take under 1s for a user with a usb stick to destroy a Meyton installation installed with the "recommended settings" during a competition (or not) if they can plug a USB stick for a few seconds in the ShootMaster computer or get access to any switch on the network with a free LAN port...
Since I got more input, I will share here and it may save someone else headaches....
So first, changing the root password in the back of the machine's user is really a bad thing. If a Linux process needs root access (and that can be legit to install a software and some services related to shoot master), this process should request the script to run as sudo *or* running it as root.
Saying that the user should login as root to install is fine but the fact that the install fails as sudo while the documentation does not mention it is NOT ok.There are also ways to check where the installer is running as root vs running as root using sudo. If that's such an issue, an error message would be nice.
I totally understand that Meyton is trying to help less-tech-savvy users but that should not be at the cost of those who follow the standard way of doing things: creating a new user, as suggested by the Suse installer, while NOT discouraged by the Meyton install guide, is an event to expect.
A good solution would be to ASK the user to provide a password for the created accounts and provide suggestions as well as a warning that if the user loses his passwords, there will be consequences. Meyton may even suggest to keep those otto/otto insecure credentials, I am fine with that as long as I don't HAVE to. Most software will actually do it the proper way and ASK you which existing user you want to use and/or propose to create a new one. So if your user is "bob", the Meyton user account (ie Meyton's Otto) will simply be "bob".
From what I learned recently, the main issue is that Meyton makes an install script mainly for MEYTON to install brand new computers in there lab. That's why they want to control the user names, passwords, IPs, etc...
And if you install your system like that, it will likely work. The issue is that some users (I am one of those...) do prepare their system before running the installation program. I am sure most users reading here have a computer and at one point created a user with their name... Well that's also what I did and that seems to confuse the Meyton installer a lot as it expects a VERY (too...) specific set of users with specific names and passwords, even the userID seems to be an issue...
Just imagine if you can ONLY install your favourite program on your computer ONLY if you never installed ANYTHING else or created any user.
Well that is what this installer seems to be doing and that's not good. The user is not to be blamed here.
Knowing this and if I would redo an install today with this knowledge I would:
- first be sad because this is not a good solution
- not recommend anyone to follow those steps as it is likely totally off road
- install a blank Suse *without any user*
- install the Meyton software
- once everything works fine, then fix the mess
There are other issues I saw in the process. For instance, the LOCAL database seems to be accessed using the IP of the computer. While that works, there is no really need for it. Using localhost or 127.0.0.1 should work all fine (there is no need to call home to talk to your wife when you *are* already home...) That requires the proper setting in MariaDB but would prevent issues related to having to change the DB IP when you change the machines IP. I know Meyton will say the IP *MUST* be 192.168.10.200 but come on... this is an IP address, not everyone HAS to use that (or should not at least) as long as the (legit) Meyton requirement of using a class B network is full-filled. Sure that will be an issue for people using ShootMaster on a remote database but I suppose there are only a few cases and those will understand how to manage there IPs... and not use 2 computers with 192.168.10.200 ...
In short, I hope this installer script will be improved based on some of the comments above.
I will have to run it again soon so I hope I will see improvements with the new versions already. I can guarantee there are nicer solutions to:
- keep non-tech-savvy users on a safe path
- free the user from having to make things soooo 100% like it is done in the Meyton lab
I will take the time for my wish list which can be taken as todo list![Lächeln :)](./images/smilies/icon_e_smile.gif)
- if the installer can ONLY run as root, check that the user is really root and not sudo, if not, show an error
- do NOT change any password in the back of the user
- do NOT create any account without asking the user for the name and password or the account (feel free to keep suggestions such as otto...)
- do NOT use a 'remote' IP when localhost can be used
- Add more logs so users can understand what is going on and what can go wrong (I still have a system hanging forever without any useful logs while running an update where ALL the checks passed...)
Would I still recommend Meyton? Yes, totally.
But I hope this installer can be fixed and I would invite Support to be a little more responsive.
I totally agree with Maximillian's previous statement: The Meyton software is great and many of the technical choices are great. However, the way security and the installation is handled is far from glorious. I am sure the motivation of Meyton is good, but the solutions are bad (for the installation script).
I wont provide details here but it would take under 1s for a user with a usb stick to destroy a Meyton installation installed with the "recommended settings" during a competition (or not) if they can plug a USB stick for a few seconds in the ShootMaster computer or get access to any switch on the network with a free LAN port...
Since I got more input, I will share here and it may save someone else headaches....
So first, changing the root password in the back of the machine's user is really a bad thing. If a Linux process needs root access (and that can be legit to install a software and some services related to shoot master), this process should request the script to run as sudo *or* running it as root.
Saying that the user should login as root to install is fine but the fact that the install fails as sudo while the documentation does not mention it is NOT ok.There are also ways to check where the installer is running as root vs running as root using sudo. If that's such an issue, an error message would be nice.
I totally understand that Meyton is trying to help less-tech-savvy users but that should not be at the cost of those who follow the standard way of doing things: creating a new user, as suggested by the Suse installer, while NOT discouraged by the Meyton install guide, is an event to expect.
A good solution would be to ASK the user to provide a password for the created accounts and provide suggestions as well as a warning that if the user loses his passwords, there will be consequences. Meyton may even suggest to keep those otto/otto insecure credentials, I am fine with that as long as I don't HAVE to. Most software will actually do it the proper way and ASK you which existing user you want to use and/or propose to create a new one. So if your user is "bob", the Meyton user account (ie Meyton's Otto) will simply be "bob".
From what I learned recently, the main issue is that Meyton makes an install script mainly for MEYTON to install brand new computers in there lab. That's why they want to control the user names, passwords, IPs, etc...
And if you install your system like that, it will likely work. The issue is that some users (I am one of those...) do prepare their system before running the installation program. I am sure most users reading here have a computer and at one point created a user with their name... Well that's also what I did and that seems to confuse the Meyton installer a lot as it expects a VERY (too...) specific set of users with specific names and passwords, even the userID seems to be an issue...
Just imagine if you can ONLY install your favourite program on your computer ONLY if you never installed ANYTHING else or created any user.
Well that is what this installer seems to be doing and that's not good. The user is not to be blamed here.
Knowing this and if I would redo an install today with this knowledge I would:
- first be sad because this is not a good solution
- not recommend anyone to follow those steps as it is likely totally off road
- install a blank Suse *without any user*
- install the Meyton software
- once everything works fine, then fix the mess
There are other issues I saw in the process. For instance, the LOCAL database seems to be accessed using the IP of the computer. While that works, there is no really need for it. Using localhost or 127.0.0.1 should work all fine (there is no need to call home to talk to your wife when you *are* already home...) That requires the proper setting in MariaDB but would prevent issues related to having to change the DB IP when you change the machines IP. I know Meyton will say the IP *MUST* be 192.168.10.200 but come on... this is an IP address, not everyone HAS to use that (or should not at least) as long as the (legit) Meyton requirement of using a class B network is full-filled. Sure that will be an issue for people using ShootMaster on a remote database but I suppose there are only a few cases and those will understand how to manage there IPs... and not use 2 computers with 192.168.10.200 ...
In short, I hope this installer script will be improved based on some of the comments above.
I will have to run it again soon so I hope I will see improvements with the new versions already. I can guarantee there are nicer solutions to:
- keep non-tech-savvy users on a safe path
- free the user from having to make things soooo 100% like it is done in the Meyton lab
I will take the time for my wish list which can be taken as todo list
![Lächeln :)](./images/smilies/icon_e_smile.gif)
- if the installer can ONLY run as root, check that the user is really root and not sudo, if not, show an error
- do NOT change any password in the back of the user
- do NOT create any account without asking the user for the name and password or the account (feel free to keep suggestions such as otto...)
- do NOT use a 'remote' IP when localhost can be used
- Add more logs so users can understand what is going on and what can go wrong (I still have a system hanging forever without any useful logs while running an update where ALL the checks passed...)
Would I still recommend Meyton? Yes, totally.
But I hope this installer can be fixed and I would invite Support to be a little more responsive.
- [MEYTON CM] kathe
- Beiträge: 707
- Registriert: Mo 4. Apr 2016, 21:56
- Verein/Verband: SV Rot a.d. Rot
Re: Installation disaster
Sorry to answer on this old thread.
We are living in a world with most Windows users and only 1-2 % Linux users.
I agree on several points.
e.g. Installer should not change root password instead it should ask for password ....
or - install a blank Suse *without any user*
or changing the user paswords in the back
but in the view of supporting one user should be always set back to defaults to ensure that the initial start works else the supporter
always needs a person sitting in front of the system. I'm also doing support worldwide and i'm getting an direct e-mail with the credentials in case i need to support if it is outside my timezone.
The system should be set into a known state after update or fresh installation. I do not wan't to confirm to much poups asking for user pw and ....
I wouldn't say it is not possible to ask for username and password..... But in the automated world this should be done automatically only after everything is installed.
Database security localhost. It should be the decision of the final user.
I'm connecting remotely to the database SSMDB running on same server and in parallel i'm also checking stuff on the meyton database.
If you restrict it to localhost many users accessing SSMDB database for their own reporting most likely windows clients will be blocked .....
Software can always be improved but what makes really sense?
Put the system behind a router firewall and only let secure stuff in the subnet.
Are you using a Smart TV then you let the hell get into your homenetwork. Always keep machines IOT stuff or security related devices complete separate and only allow specific access for specific users.
Why should a normal user see all devices in a network ? Restrict them to what they should be able and disallow everything else.
After finishing the installation it is free for the user/administrator to change all passwords.
Maybe this should be added into the manual and documentation.
Most of the users of Meyton systems are not so pc experienced people. As responsible in my club i don't wan't to get calls all the time..
I have shown them how to access the docu ..... and now it is running and i don't have much work to do.
The younger one are just playing around and they don't need a training as they read some parts of the docu and are trying to find by themselfes.
In my small club there are now more than 10 people able to operate the software without teaching them in any point.....
They are only calling if there was a real big wrong input.
Conlusion 1-2 % Linux / 99-98 % Windows
Windows users are non skilled pc users.
btw i can tell you that it was already a pain to change the installer script for suse 15.x ... i was working to improve that as first test user to install on suse 15.x .....
Which log are you missing in the setup log there is much information ?
We are living in a world with most Windows users and only 1-2 % Linux users.
I agree on several points.
e.g. Installer should not change root password instead it should ask for password ....
or - install a blank Suse *without any user*
or changing the user paswords in the back
but in the view of supporting one user should be always set back to defaults to ensure that the initial start works else the supporter
always needs a person sitting in front of the system. I'm also doing support worldwide and i'm getting an direct e-mail with the credentials in case i need to support if it is outside my timezone.
The system should be set into a known state after update or fresh installation. I do not wan't to confirm to much poups asking for user pw and ....
I wouldn't say it is not possible to ask for username and password..... But in the automated world this should be done automatically only after everything is installed.
Database security localhost. It should be the decision of the final user.
I'm connecting remotely to the database SSMDB running on same server and in parallel i'm also checking stuff on the meyton database.
If you restrict it to localhost many users accessing SSMDB database for their own reporting most likely windows clients will be blocked .....
Software can always be improved but what makes really sense?
Put the system behind a router firewall and only let secure stuff in the subnet.
Are you using a Smart TV then you let the hell get into your homenetwork. Always keep machines IOT stuff or security related devices complete separate and only allow specific access for specific users.
Why should a normal user see all devices in a network ? Restrict them to what they should be able and disallow everything else.
After finishing the installation it is free for the user/administrator to change all passwords.
Maybe this should be added into the manual and documentation.
Most of the users of Meyton systems are not so pc experienced people. As responsible in my club i don't wan't to get calls all the time..
I have shown them how to access the docu ..... and now it is running and i don't have much work to do.
The younger one are just playing around and they don't need a training as they read some parts of the docu and are trying to find by themselfes.
In my small club there are now more than 10 people able to operate the software without teaching them in any point.....
They are only calling if there was a real big wrong input.
Conlusion 1-2 % Linux / 99-98 % Windows
Windows users are non skilled pc users.
btw i can tell you that it was already a pain to change the installer script for suse 15.x ... i was working to improve that as first test user to install on suse 15.x .....
Which log are you missing in the setup log there is much information ?