anitsh
commented
3 years ago Open anitsh opened 4 years ago
anitsh
commented
3 years ago anitsh
commented
3 years ago sudo nano /etc/default/grub // Open grub and paste the two lines below
GRUB_CMDLINE_LINUX="text"
GRUB_TERMINAL=console
Execute
sudo update-grub
sudo systemctl set-default multi-user.target
If anything goes wrong and unable to boot, then edit in recovery mode:
Shift key, which will bring up a GNU GRUB menu screen. Esc key to get to the GNU GRUB menu screen.anitsh
commented
3 years ago Then I was curious about phpsessionclean.service and then some search linked to systemd-analyze.
systemd-analyze may be used to determine system boot-up performance statistics and retrieve other state and tracing information from the system and service manager, and to verify the correctness of unit files. It is also used to access special functions useful for advanced system manager debugging.
Need to review further
anitsh
commented
3 years ago A snap is a bundle of an app and its dependencies that works without modification across many different Linux distributions. Snaps are discoverable and install-able from the Snap Store, an app store with an audience of millions. Snapcraft is a powerful and easy to use command line tool for building snaps. It reads a simple, declarative file and runs the build for us.
A snap package is like a sandboxed application that is packaged in such a way that:
Now this all sounds great, and it is in some ways (especially for app developers), but it comes at a cost: and that is generally performance and annoyances with application theming, access to user folders, and the like. I personally find that if I want to run a sandboxed application I lean more toward Flatpak as it is more performant and seems a bit more mature than Canonical's snap system.
anitsh
commented
3 years ago tracker-miner-f found this running and wanted
to know it's purpose. I did not need it so I just
removed it.
anitsh
commented
3 years ago Add gpg keys to Ubuntu.
Create keys.
Register public key at Ubuntu
gpg --keyserver keyserver.ubuntu.com --send-keys 12345678
This did not work as keyserver was depricated.
gpg --send-keys PUB_KEY_ID send the keys to keys.openpgp.org.
Unable to find the CLI option to change destination, made config adjustment.
mkdir -p ~/.gnupg
echo "keyserver hkps://hkps://keyserver.ubuntu.com" | tee -a ~/.gnupg/dirmngr.conf | tee -a ~/.gnupg/gpg.conf
Setup Mailvelope Key sent. Email received for confirmation that required to be decripted with the private key. I already had Mailvelope offers email encryption with PGP for the Firefox and Chrome browsers. I need to register/upload my private keys in to the Mailvelope to decrypt the email. Email decrypted.
Confirm key registration
Opened the link. Although clicking the Confirm button it did not do anything.
Probable reason - I was logged into to launchpad. Firefox was preventing it.
Copied the link into Chrome, It worked.
gpg --list-key: List keys
The GNU Privacy Guard gnupg
dirmngr takes care of accessing the OpenPGP keyservers. it is a CRL and OCSP daemon. It is invoked internally by gpg, gpgsm, or via the gpg-connect-agent tool.
gpgsm mainly used as a backend for S/MIME mail processing. It provides digital encryption and signing services on X.509 certificates and the CMS protocol.
anitsh
commented
3 years ago https://unix.stackexchange.com/questions/127432/logging-ssh-access-attempts https://serverfault.com/questions/130482/how-to-check-sshd-log https://linuxconfig.org/how-to-open-allow-incoming-firewall-port-on-ubuntu-20-04-focal-fossa
Note that the default configuration on Ubuntu is to NOT log ssh logins to the /var/log/auth file. This is the INFO logging level.
If you want to have it include login attempts in the log file, you'll need to edit the /etc/ssh/sshd_config file (as root or with sudo) and change the LogLevel from INFO to VERBOSE.
After that, restart the sshd daemon with
sudo service rsyslog restart
After that, the ssh login attempts will be logged into the /var/log/auth.log file.
anitsh
commented
2 years ago If desktop is uninstalled, reinstall ubuntu-desktop or what ever desktop that you are using. sudo apt-get install ubuntu-desktop
https://unix.stackexchange.com/questions/326352/how-to-switch-from-cli-to-gui-ubuntu https://newbetuts.com/1138357-how-to-enable-switch-back-to-running-gui-from-tty-in-1804
sudo chvt 2 - Change to tty2
Ubuntu
Ubuntu is a general-purpose, free-as-in-speech, zero-cost operating system based on Debian GNU/Linux, designed for use on desktops, laptops, servers, and mobile devices.
The thousands of software packages available for Ubuntu are organised into four key groups or components: main, restricted, universe and multiverse. Software is published in one of these components based on whether or not it meets our free software philosophy, and the level of support we can provide for it.
Design Principles
There should be exactly one recommended way to accomplish a task in the default installation, to promote consistent documentation and support Applications should work immediately upon installation, without requiring additional steps, whenever possible. This "instant gratification" makes users more productive and allows them to explore the software choices available Features should be easily discoverable, or they will go unused The system should fit on a single CD, to make it available to the widest audience (no longer valide since ubuntu 12.10) Dialogs should conform to the GNOME Human Interface Guidelines (HIG) to promote ease of use User-visible text should be written in plain language so that non-technical users can understand what the system is telling them
System boot
The boot process of an Ubuntu system starts with the boot loader (typically GRUB) which loads the kernel and an initial ramdisk (initramfs). The initramfs sets up the console, usually including a splash screen, starts the udev daemon to process device events from the kernel, finds and mounts the root filesystem, and chains to it, mounting some important virtual filesystems along the way. Once the root filesystem is mounted, upstart takes over as PID 1, and begins to start tasks specified in /etc/init/. While this will change in the future, at the moment these tasks are essentially shims for System V init scripts and runlevels, defined in /etc/rc*.d/. In the default configuration, upstart runs the contents of /etc/rcS.d/, which sets up hardware and filesystems, and then runs the contents of /etc/rc2.d/, which starts a variety of system services. In a desktop installation, one of the services launched is an X display manager, which presents a login screen. Otherwise, the user may log in on a virtual console using one of the getty instances started by upstart.
Packages
Ubuntu packages are created in the Debian format. That is, source packages consist of a .dsc control file, plus either a .tar.gz tarball or an .orig.tar.gz tarball plus a .diff.gz patch, while binary packages are .deb files (or .udeb files for specialised use by the installer). For further information, see the dpkg manual pages and the Debian policy manual's sections on binary and source packages.
The Ubuntu policy manual applies, and is maintained collaboratively by the Ubuntu core developers. It is derived from the Debian policy manual, and technical standards are similar to those in Debian. Different standards apply to some subsystems.
Ubuntu-specific changes are logged in debian/changelog as usual, with ubuntu1, ubuntu2, etc. being appended to the version number, or -0ubuntu1 appended to the upstream version in the event that a new upstream release is needed in Ubuntu. The presence of ubuntu in a version number means that the package will not be automatically synced from Debian, and must have changes merged by hand.
Ubuntu was originally initialised by taking a copy of Debian unstable, and new versions are merged from Debian at the start of every Ubuntu release cycle in order to be able to make good use of the expertise and effort available in the Debian development community. Ubuntu developers are expected to bear this process in mind when making changes.
Package Control
Seeds are the lists of packages we want to include in the distribution. We have seven primary seeds, minimal, boot, standard, desktop, ship, live, and supported, that define what goes into the archive's main component.
Boot
The boot seed lists default kernels and boot loaders required for each processor architecture. It is kept separate from the minimal seed for technical reasons, chiefly that having debootstrap install default kernels and bootloaders reduces the flexibility of the installer to choose alternatives.
Minimal
The minimal system provides enough packages to install a basic command-line system, boot, and install more packages. It also contains any packages that should be available the first time the system boots after installation (for example, hardware detection blacklists). It does not provide X11 or any services listening on any non-localhost ports. Packages in minimal should be: absolutely stable, standard tools that we think will be around forever and we are prepared to maintain even if the whole world moves on useful diagnostic tools that one can use to get the system and network up and running, and are valuable to have "always there" in case of need widely applicable (in the Lowest Common Denominator sense) to every installation, desktop or server A "minimal" system is not expected to be useful for any particular purpose; it's simply there for bootstrapping of more interesting systems.
Standard
The standard system provides a solid foundation for a desktop or server without providing X11 or any services listening on any non-localhost ports. This seed package list, once the complete dependency set has been added, provides that system. The criteria for packages in standard are similar to those for packages in minimal, but we concentrate more on the Greatest Common Factor than on the Lowest Common Denominator: the standard system includes packages that make up a traditional comfortable UNIX system, a variety of networking clients and tools, advanced filesystem support, and various diagnostic utilities. A "standard" system is not expected to be useful for any particular purpose. It's simply the minimal working system that we will support. It should be a platform that one can quickly get working, and on top of which one can construct a useful collection of services. Typically, servers would start out life as a "standard" system, and the system administrator would then add specific services and packages as needed.
Desktop
The Desktop seed, minimally summarised, ought to be a checklist of desktop features that would appeal to a user or procurer. Our default Desktop install should include every single package mentioned in the Desktop seed. Thus, the seed should be as simple as possible without being too simple, and be directly focused on solving desktop problems. [ One of the valuable design choices in Debian is that if you install a daemon, it is assumed that you intend to use it. If you don't want to run it, don't install it. Requiring that a daemon be installed but not wanting to run it is a rarely-by-few use case, so Debian doesn't optimise for it. Rightly so. We ought to look at our Desktop seed in a similar light. If we put it on the list, it should be installed. If we install it, assume that it will be used. In some cases, this will be "running by default", but in most cases on the desktop, it just means "available or visible by default". ]
Resource