Home Home > Documentation
Sign up | Login

Archive for the ‘Documentation’ Category

How we run our OpenStack cloud

January 23rd, 2017 by

This post it to document how we setup cloud.suse.de which is one of our many internal SUSE OpenStack Cloud deployments for use by R&D.

In 2016-06 we started the deployment with SOC6 on 4 nodes. 1 controller and 3 compute nodes that also served for ceph (distributed storage) with their 2nd HDD. Since the nodes are from 2012 they only have 1gbit network and spinning disks. Thus ceph only delivers ~50 MB/s which is sufficient for many use cases.

We did not deploy that cloud with HA, even though our product supports it. The two main reasons for that are

  • that it will use up two or three nodes instead of one for controller services, which is significant if you start out with only 4 (and grow to 6)
  • that it increases the complexity of setup, operations and debugging and thus might lead to decreased availability of the cloud service

Then we have a limited supply of vlans even though technically they are just numbers between 1 and 4095, in SUSE we do allocations to be able to switch together networks from further away. So we could not use vlan mode in neutron if we want to allow software defined network (=SDN) (we did not in old.cloud.suse.de and I did not hear complaints, but now I see a lot of people using SDN)
So we went with ovs+vxlan +dvr (open vSwitch + Virtual eXtensible LAN + Distributed Virtual Router) because that allows VMs to remain reachable even when the controller node reboots.
But then I found that they cannot use DNS during that time, because distributed virtual DNS was not yet implemented. And ovs has some annoying bugs are hard to debug and fix. So I built ugly workarounds that mostly hide^Wsolve the problems from our users’ point of view.
For the next cloud deployment, I will try to use linuxbridge+vlan or linuxbridge+vxlan mode.
And the uptime is pretty good. But it could be better with proper monitoring.

Because we needed to redeploy multiple times before we got all the details right and to document the setup, we scripted most of the deployment with qa_crowbarsetup (which is part of our CI) and extra files in https://github.com/SUSE-Cloud/automation/tree/production/scripts/productioncloud. The only part not in there are the passwords.

We use proper SSL certs from our internal SUSE CA.
For that we needed to install that root CA on all involved nodes.

We use kvm, because it is the most advanced and stable of the supported hypervisors. Xen might be a possible 2nd choice. We use two custom kvm patches to fix nested virt on our G3 Opteron CPUs.

Overall we use 3 vlans. One each for admin, public/floating, sdn/storage networks.
We increased the default /24 IP ranges because we needed more IPs in the fixed and public/floating networks

For authentication, we use our internal R&D LDAP server, but since it does not have information about user’s groups, I wrote a perl script to pull that information from the Novell/innerweb LDAP server and export it as json for use by the hybrid_json assignment backend I wrote.

In addition I wrote a cloud-stats.sh to email weekly reports about utilization of the cloud and another script to tell users about which instances they still have, but might have forgotten.

On the cloud user side, we and other people use one or more of

  • Salt-cloud
  • Nova boot
  • salt-ssh
  • terraform
  • heat

to script instance setup and administration.

Overall we are now hosting 70 instance VMs on 5 compute nodes that together have cost us below 20000€

Basic Nextcloud installation on openSUSE Leap

October 28th, 2016 by

Nextcloud Logo

I see the official documentation has full tutorial for RHEL 6 or CentOS 6 and RHEL 7 or CentOS 7. The main documentation covers Ubuntu 14.04 LTS

openSUSE already has the Nextcloud client packaged in Tumbelweed and the Server is in the PHP extra repo! Personally, I prefer to install eveything from official repository, so when an update is available, I can have it without a glitch. This tutorial describes how to install Nextcloud using command line. I followed the official documentation of Ubuntu 14.04 LTS installation.

Why choose openSUSE Leap? openSUSE Leap is a brand new way of building openSUSE and is new type of hybrid Linux distribution. Leap uses source from SUSE Linux Enterprise (SLE), which gives Leap a level of stability unmatched by other Linux distributions, and combines that with community developments to give users, developers and sysadmins the best stable Linux experience available. Contributor and enterprise efforts for Leap bridge a gap between matured packages and newer packages found in openSUSE’s other distribution Tumbleweed. You can download openSUSE Leap from the site https://software.opensuse.org/.
(more…)

Highlights of YaST development sprint 25

September 28th, 2016 by

Another development sprint is over. Time flies! In our previous post we already reported about the branching of Tumbleweed and the upcoming releases and about the expected consequences: the landing of some cool features in a less conservative Tumbleweed.

We are still dedicating quite some effort to polish the upcoming stable releases (SLE12-SP2 and Leap 42.2), but in this sprint we finally found some time to play. Which is great because blogging about new features is more fun than doing it about bug fixes. 🙂

Importing Authorized Keys with AutoYaST

When logging in via SSH, public key authentication should be preferred over password authentication. Until now, the best way of setting up the required authorized_keys files in AutoYaST was using the files section.

However, that approach is tedious and error prone, as you need to make sure you set the correct owner, permissions, etc. Moreover you need to keep in sync the user definition (username and home directory) with the file definition.

AutoYaST now supports the specification of a set of public keys for each user with a pretty straightforward syntax:

<user>
  <username>suse<username>
  <authorized_keys config:type="list">
    <listentry>ssh-rsa your-public-key-1</listentry>
    <listentry>ssh-rsa your-public-key-2</listentry>
  <authorized_keys>
<user>

AutoYaST takes care of writing the files and setting the ownership and the proper permissions.

While documenting this new feature we realized the AutoYaST documentation about users management could be more detailed, which leads us to…

Improving the documentation

Usually developers love to create programs loaded with cool features but hate to write documentation. Fortunately there are people out there who enjoy writing documentation and bringing all those features to light. We have already mentioned in previous reports how grateful we are for having the SUSE documentation team polishing and publishing our documentation drafts and how open and straightforward the process is.

We updated the YaST documentation to include information about the installer self-update feature, which will debut in SUSE Linux Enterprise 12 SP2 and openSUSE Leap 42.2. As part of the same pull request and in the AutoYaST side, some additional improvements were made, including cleaning-up some duplicated information about SUSE registration.

On the other hand and as a consequence of the above mentioned new feature, the AutoYaST documentation regarding users management has been rewritten adding missing information like groups, user defaults and login settings.

All our pull requests are already merged in the doc-sle repository. At a later point in time, the SUSE documentation team will review and polish all the new content (including ours) and will publish an up-to-date version of the online documentation. If you don’t want to wait, you can easily generate an HTML or PDF version of the documentation including all the non-reviewed contributions just following the very simple instructions in the README file of the doc-sle repository.

Did we already mention we love the open source, programmer-friendly processes of the documentation team? 😉

Storage reimplementation: something you can touch

We promised news about the storage reimplementation and here they are. Our customized Tumbleweed image (labeled as NewStorage) in the storage-ng OBS repository can now perform some simple actions during installation and display the result to the user.

First of all, when proposing the timezone settings it will, as usual, check for MS Windows installations in the disk to guess if the hardware clock should be set to UTC. The news is that check is performed using the new storage stack, that offers more functionality in every sprint.

More important is that the installer will show the partitioning proposal calculated also using the new stack. As you can see in the screenshot below, the screen is way more simpler than the one you would find in a regular Tumbleweed. There are no buttons to change the settings or to run the expert partitioner yet. That doesn’t mean the functionality is not there, it’s simply that we prefer to focus first on modifying all the installer steps to use the new stack (what will enable us to use openQA) before refining every screen to add all options there.

The new partitioning proposal

Right now the system works only in disks containing a MS-DOS style partition table and will always propose a partition-based (no LVM) setup. That’s because we prefer to solve the hardest scenarios first. Using LVM and/or GPT partition tables is less challenging than the already supported scenario.

Reduce global warming by saving OBS build power

As you may know, we use the awesome Open Build Service (OBS) to generate both the YaST rpm packages and the openSUSE/SLE ISO images. Every time the source code of any component changes, OBS rebuilds that component and all the packages that depend on it.

Our beloved openSUSE and SLE release managers told us that there were several YaST packages that often triggered rebuild of other YaST packages, that triggered yet another rebuild, that triggered… you got the idea. 😉

The mentioned problem slows down the creation of new ISO images, interferes with the continuous integration process (specially visible in Tumbleweed) and wastes valuable OBS resources.

During this sprint we reduced the rebuild time of YaST by 30%. That’s for sure interesting, but knowing the details about how we did it could be even more interesting for many readers. We feared the explanation could be too complex and technical to fit into this report… which gives us just another opportunity for blogging. So expect an upcoming post including interesting technical stuff and crazy graphs like this one.

YaST dependencies graph

Some adjustment for the installer in the LiveCDs

One of the good things about working in open source is that sometimes the evolution of the projects you have created can surprise you. Quite some time ago, the YaST team dropped support for the live installer. It was simply too demanding to keep it alive while still doing our regular work (bug fixes and new features for YaST and the regular installer).

Recently the live installer was removed from Tumbleweed, the only system in which it was still available (after having been dropped in the past from stable openSUSE releases). One could have expected that somebody would decide then to step up and take the maintainership of the live installer.

But what actually happened was that Fabian Vogt decided to try a different approach we haven’t considered – adding the standard network installer to the LiveCDs images of Tumbleweed. He managed to make it work well enough and asked us for help to debug some problems. We fixed the initial problems by disabling the self-update functionality in the LiveCDs (it’s simply not designed to work on that scenario).

There are still quite some problems to be resolved to make everything work flawlessly, but if Fabian and others don’t give up, we will keep assisting them in order to bring the installation back to the LiveCDs… even in unexpected ways.

UI Designer

The YaST user interface is quite difficult to design and code. The main problem is that there is was no interactive UI designer where you could build a dialog or modify an existing one. Instead, you had to write new code or modify the existing code which creates and opens the dialog. Then, to see your changes you had to start the YaST module, go to the respective dialog and check its content. If it didn’t look like you intended, you had to close it, modify the code and start it again. And again… and again. Very annoying especially if the dialog is hidden deep in the module and you need to take several steps to get there.

During Hack Week 14, a project to improve the situation a bit was started. We already had a dialog spy which can be opened by Ctrl+Shift+Alt+Y keyboard shortcut, but that was read-only. You could only inspect the dialog tree and see the details of the selected widget but you could not change anything.

During that Hack Week project it was improved so it could edit the properties of the existing widgets, remove them or even add some new widgets. However the code was more or less a proof of concept than ready to be merged into the YaST UI and released to public. So we decided to finish it in this sprint.

As usual, it was harder than expected… but we made it and here is a short demo showing how it works and what you can do there:

The new UI designer in action

The new tool is still far from being perfect. The most obvious missing feature is that the dialog is changed in place and you cannot save or export you changes. After closing the dialog everything is lost. But it can still help to try things in the UI or make a quick prototype, specially when discussing solutions with interface designers. Hopefully we find some more time in the future to make it even better.

Storage reimplementation: encryption support

Although the partitioning proposal still does not support encryption or LVM, we implemented full LUKS (encryption) support in the underlying library (libstorage-ng). Together with the LVM support implemented in the previous sprint, that makes the new library already a valid replacement for the old libstorage in many situations and scenarios. Now it’s mainly a matter of switching from one version to another in every single YaST component, starting with the expert partitioner that we plan to start redesigning in the next sprint.

As usual, new features in the library are hard to illustrate, unless you accept the action diagrams as screenshots. In that case, here you can see the sequence of actions performed by the library when creating an encrypted home volume.

Creation of an encrypted home with libstorage-ng

Syncing keyboard layouts and console fonts in Leap and Tumbleweed

In parallel to our Scrum sprints, we have been for some time steady working, together with the openSUSE maintainers of X.Org and systemd, in redesigning how keyboard maps and console fonts are managed by YaST. Some changes were introduced in Tumbleweed some time ago but never made it to SLE (or Leap) because they needed more testing.

Recently Ludwig Nussel, the Leap’s release manager, decided that he wanted to sync 42.2 with Tumbleweed in that regard, using the new approach instead of the more conservative SLE one. Thus, we also invested quite some time coordinating again with Stefan Dirsch (X.Org) and Franck Bui (systemd) to push the changes just in time for the beta2 version of Leap 42.2… just in time to introduce bug#1000565, that was honored with its inclusion in the list of most annoying bugs in 42.2 Beta2.

The bright side is that a fix for the bug has already been provided (see bug report) and you can now finally test the new fonts and keyboard maps. Please, do so and provide feedback in order to get a properly localized Leap 42.2 release.

See you soon

As usual, this post was just a quick overview of the most interesting part of the sprint, because most people (including ourselves) don’t want to read about the boring part of the work, which is mainly fixing bugs.

The good news is that this time you will not have to wait another three weeks to read interesting stuff about YaST. As mentioned, we plan to publish a blog post about the reduction of the build time of YaST. And we will probably also publish a post about the visit of a YaST geecko to Euruko 2016.

So this time more than ever… stay tuned!

Highlights of YaST development sprint 23

August 18th, 2016 by

As already mentioned in our previous blog post, with Leap 42.2 in Alpha phase and SLE12-SP2 in Beta phase, the YaST Team is concentrating the firepower in fixing bugs in the installer. We fixed more than 40 bugs in three weeks! The dark side is that most bug fixes are not juicy enough for writing a blog post… but there is always some interesting stuff to report.

Integration of installer self-update with SCC and SMT

The installer self-update feature integrates now with SUSE Customer Center (SCC) and Subscription Management Tool (SMT) servers. Until now, there were three different mechanisms to get the URL of the installer updates repository:

  • User defined (using the `SelfUpdate` boot option).
  • Using an AutoYaST profile.
  • The default one, specified in the `control.xml` which is shipped in the media.

Now YaST2 is able to ask for the repository URL to SCC/SMT servers. The details of how the URL is determined are documented in the repository.

Fixes and enhanced usability in dialogs with timeout

As you may know, it’s possible to install (open)SUSE in an automatic, even completely unattended, basis using AutoYaST. AutoYaST can be configured to display custom configuration dialogs to the user and wait for the reply a certain amount of time before automatically selecting the default options. Until now, the only way for the user to stop that countdown was to start editing some of the fields in the dialog.

We got a bug report because that functionality was not working exactly as expected in some cases so, in addition to fixing the problem, we decided to revamp the user interface a little bit to improve usability. Now there are more user interactions that are taken into account to stop the counter, specially we added a new “stop” button displaying the remaining seconds. You can see an example of the result below.

New layout for dialogs with timeout

Following, as usual, the Boy Scout Rule we also took the opportunity to add automated tests to make that part of YaST more robust for the future.

Automatically integrating add-on repositories during installation

Sometimes you want to extend the regular installation media by adding just a few extra packages or provide a number of fixed packages along with the media.

For this purpose, the installer can automatically register an add-on repository. All you have to do is to put the repository on the installation medium and to add a file /add_on_products.xml that points to this repository.

The file looks like this:

<?xml version="1.0"?>
<add_on_products xmlns="http://www.suse.com/1.0/yast2ns"
    xmlns:config="http://www.suse.com/1.0/configns">
    <product_items config:type="list">
        <product_item>
            <name>My Add-on</name>
            <url>relurl://myaddon?alias=MyAddon</url>
            <priority config:type="integer">70</priority>
            <ask_user config:type="boolean">false</ask_user>
            <selected config:type="boolean">true</selected>
            <check_name config:type="boolean">false</check_name>
        </product_item>
    </product_items>
</add_on_products>

You can define the following elements:

  • <name> is the name of your repository
  • <url> points the the repository location; you’ll likely want to use the relurl scheme here that gives the location relative to the main installation repository
  • <priority> is the repository priority (lesser number means higher priority, the main installation repository has priority 99)
  • <ask_user>: should the user be asked about adding the repository?
  • <selected>: should the repository be automatically selected?
  • <check_name>: should the repository’s actual name be matched against the value of the <name> element?

You can of course list several repositories in this file.

If you’re too lazy to remember all this, mksusecd can do all this for you.

For example, if you have a set of new kernel packages you would like to use, do:

mksusecd --create new.iso --addon kernel-*.rpm --addon-name 'my kernel' sles12-sp2.iso

This creates a new iso based on sles12-sp2.iso that will install your new kernel packages instead.

Storage reimplementation: small steps for the code, giant leap for continuous integration

During bug squashing we managed to find some time to keep the storage stack reimplementation rolling… slow and steady. The customized Tumbleweed images (labeled as NewStorage) in the storage-ng OBS repository are already able to analyze most systems, creating a representation of the system storage devices in memory that will be used to manipulate the disks and propose a partitioning schema. Unfortunately, this representation is only visible in the YaST logs since fixing installer bugs was more urgent than representing that information in the UI.

This turned to be an important milestone, not because of the functionality itself or the value of the code (we just added a couple of lines of Ruby code), but because for the first time the dependencies in some packages were switched from libstorage to libstorage-ng. That had important implications for the code organization and for our continuous integration infrastructure, specially the Travis CI integration, which implies the generation of .deb packages. We can now say that our continuous delivery workflow (from Github to OBS, passing through Jenkins, Travis, Coveralls and Code Climate) is free of any trace of the old storage code.

In addition, we also did some good progress in LVM support in the new library, being able to recognize and manipulate in memory all kind of LVM structures.

The joy of openness: updating the SUSE Linux Enterprise documentation

An important part of our job, specially as a new release date approaches, is helping to shape the SUSE Linux Enterprise (SLE) documentation. One of the strongest points of SUSE products is the awesome SUSE’s documentation team which, as the rest of the company, have open source in their genes. Suggesting improvements and updates for the documentation is as straightforward as creating a pull request in the completely open documentation repository at Github… and anybody can do it!

The documentation team uses Docbook, but they would accept contributions in other formats (e.g. Markdown) and transform it themselves into Docbook… just because they are that cool. 🙂

Better support for ARM systems using EFI

The world is getting full of cool ARM64 devices and both SUSE and openSUSE are actively working in supporting as many of them as possible. We took another small step during this sprint improving the installer’s partitioning proposal for ARM systems that use EFI.

That’s not all, folks

As we always say, this was just the small portion of the work done that we consider exciting enough to be part of our development reports, since we don’t want to bore you with details about every single fixed bug. During this installer bug-fixing phase, this is more true than ever and the next sprint, which is already planned, will be similar to this in that regard. Nevertheless, in the next report we expect to have some interesting news about the installer self-update functionality and about the LVM support in the new storage stack. Stay tuned.

How to create an openSUSE Banana Pi M1 image with MATE Desktop

September 17th, 2015 by

I won a Banana Pi from ownCloud. So I tried to install openSUSE.

There are 3 options:

1. According to the wiki page, you can download the image they provide but there’s no kernel support for Mali400MP2 GPU (who knows if it’s fixed by now). No Mali mean no GUI. The link to image is http://download.opensuse.org/ports/armv7hl/tumbleweed/images/.

2. Download the image from http://www.lemaker.org. The GUI used is XFCE.

3. Do it the hard way, build it yourself. I would like to install MATE. I know, I could use the lemaker image.
I followed the page HowTo Build Banana Pi Image.

This post has 2 sections. The first is how to create the SD card and the next one is how to install MATE.
(more…)

DocBook Authoring and Publishing Suite (DAPS) 2.0 Released

June 23rd, 2015 by

After more than two years of development, 15 pre-releases and more than 2000 commits we proudly present release 2.0 of the DocBook Authoring and Publishing Suite, in short DAPS 2.0.

DAPS lets you publish your DocBook 4 or Docbook 5 XML sources in various output formats such as HTML, PDF, ePUB, man pages or ASCII with a single command. It is perfectly suited for large documentation projects by providing profiling support and packaging tools. DAPS supports authors by providing linkchecker, validator, spellchecker, and editor macros. DAPS exclusively runs on Linux.

(more…)

Create multi liveUSB with openSUSE

May 30th, 2015 by

I was trying to create a liveUSB with many distros. The reason is simple. All of my USB sticks were quite big for only one distro. So the rest of the USB space is wasted. For example, the openSUSE USBs I got from conferences, are 8GB. If I use installation DVD, I’m going to use only 4GB. LiveGNOME is only 1GB (the rest would be persistent drive for storage but personally, I don’t use it.

For that reason, I used 2 programs.

1. Multisystem.

I translated to Greek. Unfortunately, this software is installed only on Ubuntu/Debian distros. I used it also on Arch Linux but there was a problem lately and didn’t work correctly. On Ubuntu, I managed to insert 13.1 successfully and lately this was difficult to do. At the end of each time, there were some strange symbols running for a quite long time with a sound (I muted the sound for that reason). I think persistent drive for 13.2 and Tumbleweed wasn’t something that the creators of the program added.
DVD ISO and NET install ISO wasn’t at their list either.

2. YUMI

This works on Windows. At the end of the page there’s a version for Ubuntu/Debian (and source code). I didn’t test them.
I tested this tool and I inserted NET install ISOs to an old 512MB USB I had. The only “negative” is that there wasn’t room left for the ISOs I wanted. 90MB x 4 = 360MB. It adds syslinux stuff. Anyways, at least I can use a very old USB.
(more…)

Install ddclient on your openSUSE Raspberry Pi

May 25th, 2015 by

We’ve seen two Dynamic DNS clients. We’ll see another one here.

1. First of all, install the program.

$ zypper in ddclient

2. Create the confing file

$ nano /etc/ddclient.conf

with the following content

daemon=5m
timeout=10
syslog=no # log update msgs to syslog
#mail=root # mail all msgs to root
#mail-failure=root # mail failed update msgs to root
pid=/var/run/ddclient.pid # record PID in file.
ssl=yes # use ssl-support. Works with
# ssl-library

use=if, if=eth0
server=freedns.afraid.org
protocol=freedns
login=login_name
password=the_password
somedomain.mooo.com

Change the ones that are in bold letters.

3. Start the service

$ systemctl enable ddclient

Reboot

Upgrade your openSUSE Raspberry Pi from 13.1 to 13.2

May 24th, 2015 by

We’ve seen how to create an SD card. I used the 13.1 version. The wiki page https://en.opensuse.org/HCL:Raspberry_Pi is not very clear (to me) about resize partitions. So I tried to upgrade the version 13.1. Here what I did.

1. Check if the update repository already exists and is enabled.

$ zypper repos –uri

You should have the following enabled

3 | openSUSE-13.1-repo-update | openSUSE-13.1-repo-update | Yes | Yes | http://download.opensuse.org/ports/update/13.1/

If not, then add it

$ zypper addrepo –check –refresh –name ‘openSUSE-13.1-Update’ http://download.opensuse.org/update/13.1/ repo-update

2. Refresh and update your system

$ zypper ref && zypper update

3. Remove all third party/OBS repos you no longer need.

$ zypper lr

# Remove with

$ zypper rr (alias or number)

4. Change all remaining repo URLs to the new version of the distribution (needs to be run as root).

$ cp -Rv /etc/zypp/repos.d /etc/zypp/repos.d.Old

5. Change the repos.

$ sed -i ‘s/13\.1/13.2/g’ /etc/zypp/repos.d/*

6. Refresh new repositories (you might be asked to accept new gpg key)

$ zypper ref

If you haven’t removed third party/OBS repositories you may encounter some errors as these repositories may not exist yet or they may have different unguessable URL. It is always recommended to remove them and add their newer version after upgrade.

7. Upgrade

$ zypper dup

Now you have to wait. Reboot at the end, just to be sure that everything went smooth.

Run copy.com on your openSUSE Raspberry Pi

May 23rd, 2015 by

A good question is why do you want to sync a folder on your Raspberry Pi with a cloud service. The answer is little complicated. It’s a subproject that I’m working on right now. I want to upload some data I’ll create on a Raspberry Pi (with limited size of SD card). The uploaded data will be saved on other computer and the SD will be clear again to create new data.

The cloud service I prefer is always ownCloud.
Here I used http://www.copy.com. It provides 15GB of disk but you can increase it.

First of all download the file

$ wget http://copy.com/install/linux/Copy.tgz

Then extract it

$ tar xzvf Copy* copy/armv6h/

This will create a folder called “copy,” and in it there will be three sub-folders: “armv6h,” “x86,” and “x86_64.” The first one contains the Copy client binaries for the Raspberry Pi, the second contains the Copy client for 32-bit Linux on a PC, and the third the same client but for 64-bit Linux PCs.

$ cd /copy/armv6h

Now there are 2 ways of using copy. The CopyCmd tool and CopyConsole.

CopyCmd

List of the directories

$ ./CopyCmd Cloud -username=user@gmail.com -password=’mypass’ ls

Upload all content of local /home/user/directory/ to remote /directory

$ ./CopyCmd Cloud -username=user@gmail.com -password=’mypass’ put -r /home/user/directory/ /directory

CopyConsole

The CopyConsole tool keeps a folder on your Raspberry Pi synchronized with the data on Copy.com.
The sync app runs in the background and is started like this:

$ ./CopyConsole -daemon -username=user@gmail.com -password=’mypass’ -root=/home/user/directory

This will sync the local /home/user/directory to copy.com. If you delete something from there, it’ll delete from local folder as well.

Remeber to run this command everytime you restart your pi. It’s better to run it manually because there is username and password that are personal (unless you created an account just for your raspberry pi).