The responsibility and management of the SSH keys is left to the user, options include, but are not limited to

• Mount the keys directly in a docker volume
• Mount a host system directory directly as a volume for the keys
• Load the password protected private key from an external source and unpack within container
• Use a wrapping key on the private key file from external source and unwrap within container
• Use secure cloud service to provide keys, for example Azure Vault or AWS KMS
• Use ssh-agent to manage the keys
• Hardware device such as YubiKey

Why is there a full copy of git in the repository when in order to install the code you already needed git installed to do the installation?

There are 117 places in the scripts where /etc/*-release is attempted to be matched to determine the capabilities of the host operating system.

The code could be greatly simplified by parsing ID and ID_LIKE just once and using those field values to determine host capability

Example code

$global:ID = [string]$null
$global:ID_LIKE = @()

foreach($line in [System.IO.File]::ReadLines("/etc/os-release"))
{
	$nameValue = $line.Split("=")
	if ( $nameValue.Length -gt 1)
	{
		switch ( $nameValue[0] )
		{
			"ID" { $global:ID = $nameValue[1].Trim().Trim('"') }
			"ID_LIKE" { $global:ID_LIKE = $nameValue[1].Trim().Trim('"').Split(" ") }
		} 		
	}
}

Write-Output ( "ID=" + $global:ID )

Write-Output ( "ID_LIKE=" + $global:ID_LIKE )

On AlmaLinux this then prints

ID=almalinux
ID_LIKE=rhel centos fedora

Then to determine if the system uses "deb" packages see if ID is "debian" or ID_LIKE contains "debian"

Likewise to determine if system uses "rpm" check for ID is "fedora" or "mariner" or ID_LIKE contains "fedora"

This would greatly simplify the code in those cases.

I have built a proof of concept to build rpm and deb packages for kasini3000

This is the professional way to distribute software for Linux

This installs the content in /usr/share/kasini3000 and a symbolic link in /etc/kasini3000

Advantages over the ZIP file approach are

• File is only 20MB rather than over 200MB
• You only install the binary files you need, not what other people need
• You can let the platform sort out dependencies to rely on other packages, for example powershell
• SQL interop dll is already set to the correct version for the platform
• /usr/lib/systemd/system/kasini3000.service installed directly

[ ] The server is required, which requires payment.

You can attach packages directly to releases on Github, exactly as PowerShell does. You can also host package repositories in Oracle Cloud with the Free Tier.

[ ] It is troublesome to import the gpg key.

It is completely standard procedure for Linux, it is well documented at docker debian, docker-rpm and microsoft

All you need is to provide either clear instructions or another package which contains both the GPG public key and the repository definition as appropriate for apt or yum.

[ ] Cannot update incrementally.

If you only package what is required then you only need to issue a new version when that content has changed. Under the control of apt and yum it will update versions in place.

The README mentions "3.1 alpha 1"

How do we know what version we have installed or are available?

The repository at https://gitee.com/chuanjiao10/kasini3000 has no tags so we can't tell what version from the repository.

What is the intended release cycle? Is this intended to be a rolling release with no versions?

What is the process to ensure only good releases are used by "1incremental_update_kasini3000_from_git.ps1" on the client?

Machines will have hardware failures.

What is the recommended process for backing up and restoring both the SSH keys and CMDB on the master?

I have found that even if I created keys before running kasini3000 it would regenerate new ones over the top.

In the LICENSE.TXT it says

kasini3000 will overwrite your old ssh pub key file on linux node. ---> /root/.ssh/authorized_keys .The old pub key will invalid.

The node machine account password is stored in plain text on the master machine.

It is not considered good practice to remote login as root. As an example, when you create a new virtual machine in AWS or Oracle Cloud you get SSH with a non-root user who can then use sudo to execute administration commands.

I suggest that a similar approach is done with kasini3000 where it uses a non-root user to login and run scripts, then only use sudo for specific administration commands.

I would also suggest that once you have a public key in ~/.ssh/authorized_keys then kasini3000 no longer needs the password to the node. All access would be secure and authenticated by SSH.

This is a proof of concept. The idea is to address two issues

• The size of the Git repository versus what is required at runtime on Linux
• Running of the crontab script as root

The basic idea is to use the builder pattern in Docker, create an image that can run PowerShell and install the latest version of kasini3000 directly from git.

Within the builder, the redundant contents of /etc/kasini3000 are removed then a new image is created without the git tool installed.

When actually running the image you would use a docker volume to contain the CMDB and other contents of the data directory which would then be mounted at /root/kasini3000.

This means that Kasini3000 can run unchanged but if there are problems the docker container can be deleted, and then restarted from the image again.

The data will still be in the mounted volume.

In order to update the scripts, then the Docker image just needs to be built again getting fresh clone from the git repository.

Dockerfile

FROM mcr.microsoft.com/powershell:latest AS builder

RUN apt-get update && apt-get -y install git

RUN git clone --depth=1 https://gitee.com/chuanjiao10/kasini3000.git /etc/kasini3000

RUN rm -rf /etc/kasini3000/.git
RUN rm -rf /etc/kasini3000/master_script/kasini3000
RUN rm -rf /etc/kasini3000/lib/cwrsync
RUN rm /etc/kasini3000/lib/kasini3000/plink.exe
RUN rm /etc/kasini3000/lib/kasini3000/psftp.exe
RUN rm /etc/kasini3000/lib/kasini3000/ProgramFiles_WindowsPowerShell_Modules/WinSCP/5.17.10.0/bin/WinSCP.exe

FROM mcr.microsoft.com/powershell:latest

COPY --from=builder /etc/kasini3000 /etc/kasini3000

RUN mkdir /root/kasini3000 /root/.ssh && chmod go-rwx /root/.ssh

RUN ssh-keygen -t rsa -b 4096 -N '' -f /root/.ssh/id_rsa

CMD ["/bin/sh", "-e", "-c" , "while true; do /usr/bin/pwsh --file /etc/kasini3000/u_db_crontab.ps1; sleep 28; done"]

This is a proof of concept, you may want to generate the ssh keys outside of the docker and copy them in when building, or even keep them in another volume that is mounted at /root/.ssh. This proof does not show the setting up the Interop DLLs required for SQLlite.

SHA1 is considered deprecated

52 occurrences of "sha1"

run_win2linux_key_pwd.ps1

$主控机公钥sha1 = Get-FileHash -Algorithm sha1 -LiteralPath "${global:kasini3000_data_path}\ssh_key_files_old1\authorized_keys"
$被控机公钥sha1 = Invoke-Command -Session $private:连接111 -ScriptBlock { Get-FileHash -Algorithm sha1 -LiteralPath '/root/.ssh/authorized_keys' }
Write-Verbose ("公钥： {0} '---' {1} " -f ${主控机公钥sha1}.Hash,${被控机公钥sha1}.Hash)
if ($主控机公钥sha1.Hash -ne $被控机公钥sha1.Hash)

Hi, project page says project supports Raspberry Pi.

When looking at zkj_install_powershell_从win主控机到linux被控机.ps1 it refers to amd64.

I see no references for either aarch64 or any 32 bit arm architectures.

What Raspberry Pi operating systems does it support?

Thanks.

It's easy to determine if it's the original program. Check the software signature on properties page of the right mouse button or go to the official website to compare the sha256 value.

The version of System.Data.SQLite.dll is 1.0.112.0.

This is not listed at https://www.sqlite.org/download.html or https://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki.

I finally tracked it down to https://system.data.sqlite.org/downloads/1.0.112.0/sqlite-netStandard20-binary-1.0.112.0.zip

unzip -l  sqlite-netStandard20-binary-1.0.112.0.zip
Archive:  sqlite-netStandard20-binary-1.0.112.0.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
   351744  2019-10-27 06:31   System.Data.SQLite.dll
    12492  2019-05-15 00:31   System.Data.SQLite.dll.config
   117056  2019-10-27 06:31   System.Data.SQLite.pdb
  1094797  2019-10-27 06:31   System.Data.SQLite.xml
---------                     -------
  1576089                     4 files

The files sizes match and so does the SHA256 for System.Data.SQLite.dll.

I was unable to find the interop dlls. The closest I could find was the NuGet package which is 1.0.103.0

https://www.nuget.org/packages/SQLite.Interop.dll/

The version included in the project is 1.0.111.0.

Where do the interop dlls come from? Thanks.

For the security of the Linux host computer, I recommend using alpine linux for the following reasons:

• Its software package is small and safe enough.
• It takes up memory and has very little cpu.
• The Kasini 3000 can use both the Windows host and the Linux host at the same time.
• It is basically live cd, that is, linux started from iso. Just download the new iso version to complete the linux upgrade.
• It supports installation to the hard disk. After installation, you can still start through the ios on the CD, which basically does not take up hard disk space.
• You can store the/etc/kasini3000 directory on the hard disk and install the powershell on the hard disk.
• Using kasini3000 in alpine linux is no different from the other linux distribution.

I have also tried microsoft cblm 2.0, which seems to be not well. The main reason is that after installation on the hard disk, it takes up a lot of disk space, which is no different from the ordinary Linux distribution.

Steps to reproduce

1. clone the repository with

git clone https://gitee.com/chuanjiao10/kasini3000.git kasini3000

2. move into the repository and checkout 26e895d6cc47d75718c73525660c6e7c010737ec, this is when the repository was using git 2.35.1.2

3. Now run the git.exe to update to current version of git in the repository

.\master_script\kasini3000\git\mingw64\bin\git.exe checkout master

Result is

Unlink of file 'master_script/kasini3000/git/mingw64/bin/git.exe' failed. Should I try again? (y/n) y
Unlink of file 'master_script/kasini3000/git/mingw64/bin/git.exe' failed. Should I try again? (y/n) y
Unlink of file 'master_script/kasini3000/git/mingw64/bin/git.exe' failed. Should I try again? (y/n) y
Unlink of file 'master_script/kasini3000/git/mingw64/bin/git.exe' failed. Should I try again? (y/n) n
error: unable to unlink old 'master_script/kasini3000/git/mingw64/bin/git.exe': Invalid argument
Updating files: 100% (1431/1431), done.
Previous HEAD position was 26e895d 更新：git库到2.35.1.2
Switched to branch 'master'
M       master_script/kasini3000/git/mingw64/bin/git.exe
Your branch is up to date with 'origin/master'.

End result is that git.exe is unable to update itself in the repository on Windows.

.\master_script\kasini3000\git\mingw64\bin\git.exe --version
git version 2.35.1.windows.2

In master, it should currently be

git version 2.35.3.windows.1

Hi, interesting project and I like the cross platform support. I suggest don't install system from git, use a packaging mechanism to install exactly one version. On Linux I suggest /usr/share/kasini3000 would be a better location than /etc/kasini3000, the /etc location should only be for local configuration files. Use a DEB or RPM to install the required files on Linux. Likewise on Windows it would be better installed by MSI in c:\Program Files\kasini3000 with only local data files under c:\ProgramData\kasini3000. Using packages you can then update in place with new versions and use standard packaging mechanisms to know what is installed on any node. Data managed on Linux should be in say, /var/lib/kasini3000 rather that /etc/kasini3000.

Hi, you have a version history at https://gitee.com/chuanjiao10/kasini3000/wikis/news

But this is hard to match against the git repository using standard tools and for non Chinese readers.

Can you put git tags on the commits that match the formal releases? I recommend tags in plain ASCII with the simple release version.

This would make it easier for all users of your git repository to see the formal release history and allow tools to clone specific releases.

Cloning the whole repository, stepping through the git log and trying to parse kasini_version.ps1 is not very efficient.

It will make the git repository look well managed for a product with formal releases.

Thanks,

You have a systemd service to invoke u_db_crontab.ps1

u_db_crontab.ps1 contains test for the the value of minutes before performing certain tasks.

You could use the onCalendar systemd timer mechanism in order to simply run scripts at scheduled times rather than programmatically trying to determine the time.

Likewise on Windows one can use scheduled tasks for the equivalent mechanism.

Hi, I am looking at using a Windows machine to manage a small set of Linux machine ( a couple of raspberry pis. ).

If kasini3000 is not run as an administrator, what functions will be unavailable?

I was hoping that as normal user it will still be able to ssh onto the nodes to run scripts and also run scheduled tasks.

Packaging Windows software as an MSI is the standard way to deliver software in managed environments.

It can be installed simply from Explorer or using msiexec. It can be easily removed using "Add and Remove Programs" and msiexec.

With well managed curation of the content in the MSI it can be under 20MB.

With a proper software release cycle you can produce an MSI for each version.

Visibility in "Add and Remove Programs" means the user is aware what is installed.

I notice that when following the installation instructions for Linux users, that none of the *.ps1 files have the execution bit set.

It is traditional, in a Linux environment, to simply be able to run scripts from the command line no matter what interpreter they use.

For PowerShell this means adding this as the first line..

#/usr/bin/env pwsh

This would be before the param block.

Then set the execution bit for the program using...

chmod +x xxxx.ps1

To update this in git use

git add --chmod=+x xxxx.ps1

So then for Linux users they don't have to prefix running a PowerShell script with "pwsh".

The purpose of the dpkg lock files is to protect the integrity of the package management system.

The sequence "rm -rf /var/lib/dpkg/lock;rm -rf /var/lib/dpkg/lock-frontend;" occurs in multiple places.

This is not good practice and risks corrupting the package management system and preventing normal operating system updates.

There are reports of Trojanized versions of PuTTY being distributed. These are versions of the original PuTTY but a backdoor has been added to the code.

For example: https://www.microsoft.com/security/blog/2022/09/29/zinc-weaponizing-open-source-software/

I notice that the git repository contains files such as psftp.exe and plink.exe which appear to be PuTTY programs.

How can we have confidence that the binary versions distributed by kasini3000 are not malicious versions?

I suggest the mount directory should be treated as data so should be in the data directory, not the program directory

Hi,

Thanks for the invite to kick the tyres of your project. It is certainly interesting and I wish you well with it.

You have made design choices along the way as any developer must do.

For me the two main roadblocks to using the project are the installation, mainly using git to install binary packages, and the use of root on Linux. But you are free to make your choices in your project.

Thanks again

The instructions are to copy the Linux interop dll over the default installed windows dll.

https://gitee.com/chuanjiao10/kasini3000/blob/master/docs/install_kasini3000master_to_raspberry.md

As this is a git repository and users are encouraged to pull to get updates, if the original windows dll is updated in the origin repository, it will conflict with the change made by coping the linux version in its place.

As far as I can tell kasini3000.service is running u_db_crontab.ps1 as root.

It is best practice to run services as a non-root user and then only use sudo or set-uid in order to invoke limited functions that require root access.

A master node should not need to run anything as root on the master node while it is administering child nodes. The cases for running sudo should be limited to the single command required to perform the administration on the target system.

Running as non-root is best practice because it means that errors or misconfigurations in your application are much less likely to affect the rest of the system. It also provides less opportunity for your application to be inadvertently turned into a backdoor.

Postfix, apache, tomcat, systemd itself and many other well-behaved applications don't run the services as root.

While kasini3000 could be run within a docker container it would be without systemd, and if running as root within the docker it could still corrupt the files within the container due to misconfiguration or programming error.

Is this correct?

/usr/bin/scp /etc/kasini3000/ssh_key_files_old1/authorized_keys root@${目的ip地址}:/root/.ssh/

I thought the key files were in the data directory

/root/kasini3000/ssh_key_files_old1

Effectively, the /etc/kassini3000 directory is really the program directory which should be treated as read only.

As far as I can tell, the SQLite.Interop.dll is the only native compiled component required for Kasini3000 ( apart from the correct PowerShell binaries being installed )

If you want to compile the matching SQLite.Interop.dll for ARM64 then you can get the 1.0.112.0 source from

https://system.data.sqlite.org/blobs/1.0.112.0/sqlite-netFx-source-1.0.112.0.zip

To build this on ARM64 Linux, unpack the zip in an empty directory and

cd Setup
bash ./compile-interop-assembly-release.sh

The result should be in

bin/2013/Release/bin/SQLite.Interop.dll

Binary files don't belong in a source code repository.

For example it looks like EXE and DLL from Cygwin are in https://gitee.com/chuanjiao10/kasini3000/tree/master/lib/cwrsync

If you use 3rd party components or projects then reference the original source for that component and make it a dependency.

Hi,

I had a look at bkj_install_linuxpackage.ps1 and bkj_remove_linuxpackage.ps1 and have some recommendations.

The identification of the platform would be improved by focusing on the ID and VERSION_ID fields in /etc/os-release rather than current pattern matching. Many of the patterns in the code don't match this record of existing /etc/os-release files.

There is a lot of code duplication between the two programs that I am sure could be shared.

It would also be simplified by identifying the package API type by operating system and using common routines rather than a function per operating system version.

There are question-marks around Amazon Linux in the code. ID="amzn" VERSION_ID="2" uses yum and rpm.

I don't know why there are "Start-Sleep" in the code or why you are trying to force delete the /var/lib/dpkg/lock* files. They are there for a reason and one should leave the operating system itself to manage its synchronisation and protection of the repository database files.

Some parts of the code use sudo, and other lines immediately next to them don't even though using a command that needs root access, eg the ubuntu cases in bkj_remove_linuxpackage.ps1

Apart from the exit 1 if the operating system is Windows, the scripts have exit 0 at the end. How does the caller know if they were successful?

Normally the path for bash is /bin/bash just like /bin/sh

Can you not use normal PATH resolution for bash?

/usr/bin/bash: /etc/kasini3000/gx更新主控机ssh秘钥2z.ps1:129
Line |
 129 |  "@ | /usr/bin/bash
     |       ~~~~~~~~~~~~~
     | The term '/usr/bin/bash' is not recognized as a name of a
     | cmdlet, function, script file, or executable program. Check
     | the spelling of the name, or if a path was included, verify
     | that the path is correct and try again.

I see that a global variable is used to hold the data path.

$global:kasini3000_data_path = "/root/kasini3000"

and

$global:kasini3000_data_path = "${env:USERPROFILE}\Documents\kasini3000"

This is good and aids portability between Linux and Windows.

There are 37 other occurrences where /root/kasini3000 has been hard-coded. For example

Remove-Item -Path '/root/kasini3000/ssh_key_files_old2/*'

These should be replaced with the variable and hence make the scripts more consistent and portable.

config.ps1, gtnode.ps1 and others refer to .ssh/id_rsa

RSA key format for SSH usage is being deprecated by OpenSSH.

https://www.openssh.com/txt/release-8.2

Suggest update to better algorithm, for example ECDSA or Ed25519.

Most software allows the user the option of where to install software and then configure it using environment variables so it can operate

For example..

DOTNET_HOME
JAVA_HOME
CATALINA_HOME/CATALINA_BASE
ANSIBLE_CONFIG
GIT_EXEC_PATH

Suggest that kasini3000 uses an environment variable to determine where its files are to support users who don't want to use the default install location.