Apparently Shuttleworth announced at the OpenStack Summit that Ubuntu 18.04 will have ten years of support (originally cited ZDnet article). But neither the Ubuntu website nor the Ubuntu wiki have been updated to reflect that.
What exactly is included in this ten-year support?
I'm not looking for speculation or guesses or indications. I'm looking for verifiable, official information.
I noticed that the htop package for 18.04 is in main, where previous releases had it in universe. This is reflected in the packages index and on Launchpad. Software in main is supported by Canonical, these are usually either part of the default install (or the installer), or widely-used server software.
htop is pretty good, it'd be nice to have it in the default installation.
How can I find more about how and why htop got included in main?
I have a device on which I would like to install Ubuntu. How do I find out if Ubuntu will work on it?
I have always found the source code browser of Launchpad extremely useful when I need to link to packaging code in an answer. The URL pattern is simple enough (https://code.launchpad.net/ubuntu/+source/<package>) that I can often just replace the last word after typing code in my address bar. But, of late, I have found that it's been increasingly inconsistent to find the actual packaging code.
For example:
Note that there's no Git repositories listed for GDM packaging. Others like GDM: bazaar itself, LightDM, zsh, Chromium, ...
Where did all that packaging code go?
Note that I don't want to download the packaging code, I have apt-get source for that. I don't want to browse the software source code, I'd look outside LP for that (unless, of course, the software is developed on LP). I want to browse the packaging code for Ubuntu online, and be able to link to it. For Debian, I can usually dig up the packaging on Alioth.
While keeping track of USNs for the Stack Clash vulnerability, I noticed that already published USNs were showing up before ones published later. USNs 33{24..27}-1 were originally published on the 19th, and now they show a date of 21st (compare the webpage with the mailing list post for 3324-1). For 3324-1, it seems some kernel packages were dropped from the list. However, it is tedious to examine all the updated USNs manually.
Is there a place where I can see what changed in a USN?
Aside: why would they update an USN, instead of posting a new one and incrementing the number after the hyphen?
I have heard about a new vulnerability named Stack Clash which apparently affects multiple Unix-like systems (not just Linux, but the BSDs, Solaris as well).
snapcraft cleanbuild is supposed to let me build snaps in clean-room environments. Accordingly it starts from a minimal LXD image and installs necessary packages. However, it seems to use the base archive.ubuntu.com mirror, which is excruciatingly slow. How do I cache the packages it download?
I could set up apt-cacher-ng or another caching proxy, but there's still the problem of getting the snap/LXD combination to use it. It would be best if it had an internal cache like pbuilder does, but if not, then how do I convince it use a different mirror or a proxy for the mirror?
While building Debian packages, pbuilder (and similar tools) help in building packages in an isolated environment, so that odd settings in my system don't cause problems in building:
pbuilder aims to be an easy-to-setup system for auto-building Debian packages inside a clean-room environment, so that it is possible to verify that a package can be built on most Debian installations. The clean-room environment is achieved through the use of a base chroot image, so that only minimal packages will be installed inside the chroot.
Is there an equivalent for snapcraft?
Context: I just had some locale problems interfere with building a snap for Cassandra. I'd been getting locale errors that I am too lazy to look into, and during the build process, javadoc failed because of Unicode characters in some files. Using C.UTF-8 as the locale fixed that:
export LC_ALL=C.UTF-8
snapcraft
However, my locale shouldn't affect building packages, snappy or Debian. Something like pbuilder would be useful here.
The snap packaging format finally frees us from dependency hell by allowing each package to have its own copy of dependencies. I'm interested in the technical details in how it does this. How does it handle:
xdg-app has something called a "runtime":
A fundamental concept in xdg-app is the runtime/application split. Every app depends on a runtime, which supplies the core libraries that the app relies on. Runtimes are typically shared by many applications, but a user can have multiple runtimes installed at the same time.
It seems that in the case of OpenSSL, it would be part of the runtime in xdg-apps, so an update to OpenSSL should transparently affect all xdg-apps using the same runtime.
It's already known that the guest account can't use su or sudo:
How is this done?
My guess would be apparmor. However, there's no mention of either in /etc/apparmor.d/lightdm-guest-session (or other files included in it).
Is it done by denying some capability?
$ grep cap /etc/apparmor.d/abstractions/lightdm
capability ipc_lock,
deny capability dac_override,
deny capability dac_read_search,
dac_override seems to be a good candidate. According to man capabilities:
CAP_DAC_OVERRIDE
Bypass file read, write, and execute permission checks. (DAC is
an abbreviation of "discretionary access control".)
CAP_DAC_READ_SEARCH
* Bypass file read permission checks and directory read and
execute permission checks;
* Invoke open_by_handle_at(2).
Is this it, or is it some other capability? Or is it not apparmor at all?
Apparently, it's the setgid capability. From syslog for a su attempt:
Mar 18 12:14:52 muru-wily kernel: [ 5285.025017] audit: type=1400 audit(1458283492.316:159): apparmor="DENIED" operation="capable" profile="/usr/lib/lightdm/lightdm-guest-session" pid=25687 comm="su" capability=6 capname="setgid"
However:
$ sudo grep setgid /etc/apparmor* -R
/etc/apparmor.d/disable/usr.sbin.rsyslogd: capability setgid,
/etc/apparmor.d/usr.sbin.tcpdump: capability setgid,
/etc/apparmor.d/cache/.features:caps {mask {chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
/etc/apparmor.d/usr.sbin.cupsd: capability setgid,
/etc/apparmor.d/usr.sbin.cupsd: capability setgid,
/etc/apparmor.d/usr.sbin.rsyslogd: capability setgid,
/etc/apparmor.d/abstractions/lightdm_chromium-browser: capability setgid, # for sandbox to drop privileges
/etc/apparmor.d/abstractions/dovecot-common: capability setgid,
/etc/apparmor.d/abstractions/postfix-common: capability setgid,
Aside from the .cache folder, nothing seems to be restricting setgid. However, man apparmor.d says:
Capabilities
The only capabilities a confined process may use may be enumerated;
If I understand correctly, then if any capabilities are listed, then only those can be used - all others are restricted. Does the capability ipc_lock line automatically restrict all other unmentioned capabilities? If so, why deny capability dac_override and deny capability dac_read_search?
http://manpages.ubuntu.com is a great resource for viewing manpages not installed in the system. However, it uses some weird programming to redirect short URLs like http://manpages.ubuntu.com/ls.1 to http://manpages.ubuntu.com/manpages/wily/en/man1/ls.1posix.html, and it always picks the latest release. Otherwise, it works fine when using lynx with the full URL. It even looks like a normal manpage:
The redirection doesn't work in lynx (or elinks or w3m). Just to check, I tried on my Arch Linux elinks, which apparently does support JavaScript:
$ elinks -version
ELinks 0.13.GIT a3751107033599b835eaafa61177c8d4dda4b7ef-dirty
Built on Oct 31 2013 20:43:18
Features:
Standard, IPv6, gzip, bzip2, UTF-8, Periodic Saving, Viewer (Search
History, Timer, Marks), Cascading Style Sheets, Protocol
(Authentication, File, CGI, FTP, HTTP, URI rewrite, User protocols),
SSL (OpenSSL), MIME (Option system, Mailcap, Mimetypes files), LED
indicators, Bookmarks, Cookies, ECMAScript (SpiderMonkey), Form
History, Global History, Scripting (Lua, Spidermonkey ECMAScript), Goto
URL History
edbrowse didn't redirect either. That's that for the suggestions from Is there a text mode browser which supports javascript?
Using the full URL would be workable if I knew the section, which is not always the case. Is there a program which can bring up the online manpage, preferably for the running Ubuntu version? In case of matches in multiple sections, it should behave like man does.
Many sysv init scripts used a corresponding file in /etc/default to allow the administrator to configure it. Upstart jobs can be modified using .override files. How do I override or configure systemd units, now that systemd is the default in Ubuntu?
While using byobu, my terminal tab's title is set to user@fqdn (IP) - byobu, which can be pretty long depending on the domain. How can I limit it to something shorter, like user@hostname, or better yet, let zsh set the title? I have tried setting BYOBU_NO_TITLE=1, following this bug, but that, I think, allows the local shell to set the title, not the remote one.
This can be very annoying, since Terminator sets every tab header's length to the same, so one very long title is enough to make all of them very long. Worst case, I'd like it if I could simply trim off some of it to a maximum length (like user@f ... byobu).
I already have added a function to .zshrc to set the title:
case $TERM in
xterm*|screen*)
if [[ -n $SSH_TTY ]]
then
precmd () {print -Pn "\e]0;%m: %~\a"}
else
precmd () {print -Pn "\e]0;%~\a"}
fi
;;
esac
This works if I don't use byobu:
The tab on the left is an SSH session without byobu, and the one on the right is with byobu.
With Serg's suggestion of setting IP_EXTERNAL to 1, I can get rid of the IP, shortening the title. I'd prefer a solution that passes on the title set by zsh (or other applications, such as Vim) to the terminal - it looks like byobu/tmux blocks them.
nginx on Ubuntu is a virtual package provided by one of five packages from the official repositories (at least as of 14.04, defaulting to nginx-core, I believe):
$ apt-cache depends nginx | tail -n+2 | cut -d: -f 2 | sort -u
nginx-core
nginx-extras
nginx-full
nginx-light
nginx-naxsi
What is the difference between these packages and what are the recommended use cases for them?
This somewhat old Debian Wiki page has a feature comparison between extras, full, light and naxsi, but no mention is made of core. How much of it has changed in 14.04?
secondary
As I understand it, nginx doesn't support runtime enabling of modules like Apache does, so would installing nginx-extras impact performance?
The usual method of adding your own CA certificate to Ubuntu is:
cp cert.pem /usr/local/share/ca-certificates
update-ca-certificates
I'd like to distribute my CA certificate using a Debian package, but /usr/local/ is off-limits to packages (and lintian complains, and the Software Centre denounces my package as a low-quality one). So what's the standard method for doing so using Debian packaging? I tried peeking at ca-certificates-java, but I couldn't make much sense of what it is doing.
Two answers in this question state that screen is unmaintained. However, the GNU repository of screen shows an upload this year after 6 years, and 14.04 has two newer versions than the earlier Ubuntu releases (one in the main release, and one in backports, from 14.10). Unmaintained software get dropped from Ubuntu, but screen remained even after a six-year period of inactivity. So what is the status of screen in general, and in Ubuntu? Will it remain (reasonably) maintained, or should I switch to tmux or other alternatives?
I would like to disable or change the MOTD shown on SSH login on a per-group/per-user basis. This question on SuperUser has an answer stating that I can use Match blocks in sshd_config. However, man sshd_config states:
Match
...
Only a subset of keywords may be used on the lines following a
Match keyword. Available keywords are AcceptEnv,
AllowAgentForwarding, AllowGroups, AllowTcpForwarding,
AllowUsers, AuthenticationMethods, AuthorizedKeysCommand,
AuthorizedKeysCommandUser, AuthorizedKeysFile,
AuthorizedPrincipalsFile, Banner, ChrootDirectory, DenyGroups,
DenyUsers, ForceCommand, GatewayPorts, GSSAPIAuthentication,
HostbasedAuthentication, HostbasedUsesNameFromPacketOnly,
KbdInteractiveAuthentication, KerberosAuthentication,
MaxAuthTries, MaxSessions, PasswordAuthentication,
PermitEmptyPasswords, PermitOpen, PermitRootLogin, PermitTTY,
PermitTunnel, PubkeyAuthentication, RekeyLimit,
RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset,
X11Forwarding and X11UseLocalHost.
And I can't see anything related to MOTD in that list. And indeed, trying to use that suggestion causes sshd to fail to start because of incorrect configuration.
So, can I do this? If so, how? From the SSH configuration or by altering whatever generates/prints the MOTD?
Altering files in /etc/update-motd.d isn't useful, since, according to man update-motd:
Executable scripts in /etc/update-motd.d/* are executed by pam_motd(8)
as the root user at each login, and this information is concatenated in
/var/run/motd.
(I tested this out with a script that did echo $USER. I got a root in my MOTD.)
That leaves PAM configuration. I imagine it might be possible to disable pam_motd on a per-group/user basis, but I am not sure how to do it. The last option would be to disable pam_motd altogether, and use pam_exec, but I really hope it doesn't come to that.
The manpage for apt.conf doesn't mention SOCKS at all. Yet there are a few questions about SOCKS and apt here, and every now and then I see an answer which has something like:
Acquire::http::proxy ..
Acquire::https::proxy ..
Acquire::ftp::proxy ..
Acquire::socks::proxy ..
(all four) in them. Acquire::socks doesn't raise an error, but doesn't seem to have an effect either.
What exactly is the state of support for SOCKS proxies in apt?
The old-releases.ubuntu.com mirror hosts the repositories for EOL Ubuntu releases. The main page currently lists up to 11.10 (or 12.04.3 if you count point upgrades), but the dists page lists up to 13.04. Why the discrepancy? When will the main page be updated? When will the newest EOL release (13.10) be shifted here?
I am creating a configuration package, and would like to stop and restart services whose configuration is affected. Right now I am using the service [stop|restart] in {pre,post}{inst,rm} way. I read in a question somewhere that invoke-rc.d is the right way, because it honours user preferences about a service. However, I couldn't find any guidelines about this. Does anyone know of such guidelines? Or have any advice as to which way I should pick? The package is of internal use, and will likely only be for 14.04 for the next two years. However, I'd like to leave as clean a state as possible for my successor, so systemd is in my mind as well.
From the invoke-rc.d man page:
All access to the init scripts by Debian packages' maintainer scripts should be done through invoke-rc.d.
From the Debian Policy Manual, Chapter 9, Section 3.3:
Maintainers should use the abstraction layer provided by the update-rc.d and invoke-rc.d programs to deal with initscripts in their packages' scripts such as postinst, prerm and postrm.
...
The package maintainer scripts must use invoke-rc.d to invoke the /etc/init.d/* initscripts, instead of calling them directly.
Debian has been using sysv-init and will shift directly to systemd, and I suppose the policy manual will be updated in due time to refer to systemctl. However, what I am uncertain about is this: Should I use invoke-rc.d instead of service? I can tell dpkg that I am interested in some files (via triggers), so is there a way to tell dpkg that I am interested in some services as well and get dpkg to do the restarting/reloading?
To clarify: I am not writing init scripts. I am providing a package with configuration for other applications, like Puppet, NTP, etc., so I stop and restart the corresponding services in the scripts.
Here, for example, is a Docker issue about invoke-rc.d vs service. The issue is still open, with one person, probably a maintainer, commenting that they are definitely interested in doing this the right way - clearly neither of us are sure what that is. (My question is independent of that issue.)