1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
/****************************************************************************
**
** Copyright (C) 2019 Luxoft Sweden AB
** Copyright (C) 2018 Pelagicore AG
** Contact: https://www.qt.io/licensing/
**
** This file is part of the documentation of the Qt Auto Deployment Server.
**
** $QT_BEGIN_LICENSE:FDL-QTAS$
** Commercial License Usage
** Licensees holding valid commercial Qt Automotive Suite licenses may use
** this file in accordance with the commercial license agreement provided
** with the Software or, alternatively, in accordance with the terms
** contained in a written agreement between you and The Qt Company. For
** licensing terms and conditions see https://www.qt.io/terms-conditions.
** For further information use the contact form at https://www.qt.io/contact-us.
**
** GNU Free Documentation License Usage
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of
** this file. Please review the following information to ensure
** the GNU Free Documentation License version 1.3 requirements
** will be met: https://www.gnu.org/licenses/fdl-1.3.html.
** $QT_END_LICENSE$
**
****************************************************************************/
/*!
\ingroup qtauto-deployment-server
\page index.html
\nextpage Qt Automotive Suite Deployment Server Installation
\startpage Qt Automotive Suite Deployment Server
\title Qt Automotive Suite Deployment Server
\note This project is not maintained anymore. It was ported to a Qt 6 cmake setup and a more
modern Django and Python version to at least keep it usable for legacy projects.
For non-production use-cases, please switch to the new
\l{Package-Server}{appman-package-server}
available in the \l{Qt Application Manager} starting with version 6.7.
The Qt Automotive Suite Deployment Server is a new component in the Qt Automotive Suite 5.12.
Previously, it was known as the Neptune Appstore and used for demonstrations purposes.
This component is a lightweight HTTP server that provides network feeds to application packages
that are available for installation by a Qt Application Manager instance, running on a target
device connected to a network. The UI counterpart for the Deployment Server is the Downloads app
in the Neptune 3 UI. Together, the Deployment Server and the Downloads app enable you to install
different apps available on the server through network.
The key scenario for these components is to install apps during the integration testing
process. Additionally, the code can also be used as a reference implementation for a
fully-featured server, and a new Downloads app on the target device for production.
The Deployment Server works with the Application Installer in \l{Qt Application Manager} and
acts as an installation source for \c{http://} and \c{https://} schemes. In addition to
application packages, the Deployment Server also hosts meta information about each package,
that is used by Downloads app to visualize the choices available for a user to select.
This meta information is stored in the form of tags and other information in the package
header, according to the Qt Application Manager’s package format. When a package is uploaded
to the server, the package header is parsed, associated with that package, and then sent to the
Downloads app, that queries for a list of available apps. Using this information, the Downloads
app can inform users about the available apps and even hide those that are not compatible
with the target installation. The figure below illustrates this installation scenario.
\image deployment-server-installation-handshake.png "Install an App via the Deployment Server"
The Deployment Server is implemented in Python, using Django, based on the following assumptions.
\section1 Assumptions
\list
\li Applications are identified with a group of: Application ID, version, architecture, and tags;
these groups are unique.
\li Architecture is specified as a group of: CPU architecture, endianness, bitness, and OS.
If a package does not contain architecture specific parts, the architecture is specified as \e{All}.
\li CPU architecture is based on the return value from QsysInfo::buildAbi() and
QSysInfo::kernelType(), joined with '-'.
\li The installation target is automatically determined by parsing binary files. For example,
detecting an ELF binary means that it's a Linux package; the CPU architecture, such as armv8,
further defines the installation target.
See \l {https://doc.qt.io/qt-5/qsysinfo.html#kernelType} {QSysInfo::kernelType()} for more details.
\li If both native and non-native applications match the selection criteria, then the native application
is preferred.
\li Applications can be further filtered by tags, both as positive (inlucde) and negative (exclude)
filters.
\li Tags are considered alphanumeric and can contain lowercase Latin letters, numbers, and
the underscore symbol. All tags passed to the server are converted to lowercase.
\li Tags can also have an optional version. The version number is separated from tag using a colon (:).
Similar to tags, the version can contain lowercase Latin letters, numbers, and the underscore symbol.
\li Tags are matched according to versions. For example, if you request for "version 5.12", this matches
with "5.12.0", but not vice versa. If you request for a non-versioned tag, any version matches your request.
\li Tag lists in requests and packages are simplified. For example, "qt:5.12,qt:5.12.0" is reduced to "qt:5.12".
\li Although the \l {https://doc.qt.io/QtApplicationManager/manifest.html#basic-manifest} {Application manifest}
allows for any number of categories to be assigned to an application, currently, the Deployment Server
requires manual assignment of only one category to the application. Categories in the application manifest
are ignored.
\li Tag information is parsed from the package header's \b{extra} and \b{extraSigned} parts,
from \b{tags} array. All elements of that array are added to package’s tag list.
\li Each package has a version number. If the manifest does not contain a version field, a default
version "0.0.0" is assigned.
\endlist
\note In order to create a tagged package you can use appman-packager with \c{-m} parameter, for example:
\code
appman-packager create-package package.pkg package-tmp/apps/com.luxoft.alexa/ -m "
{tags: ['platform:desktop']}" --verbose
\endcode
This command creates package and adds \c{platform} tag with \c{desktop} value to it.
For reference see the \l{Packager} section of \l{Qt Application Manager} documentation.
\section1 References and procedures
\list
\li \l{Qt Automotive Suite Deployment Server Installation}
\li \l{Qt Automotive Suite Deployment Server API Reference}
\li \l{Set up a Production server with Apache, Lighttpd or Nginx}
\li \l{Upload Packages to the Deployment Server}
\endlist
*/
|
